duplicity-team team mailing list archive

[Kenneth Loafman <kenneth@xxxxxxxxxxx>]

Not sure I like the idea of a mock backend.  I'm thinking more along the
lines of a duplicity API doc for backends that handles get, put, list, del,
etc., where our wrapper would handle any retries so that those would be the
primitives, not the full implementation.  We'd then have a way to put out a
series of test cases for a new backend that would test separately from
duplicity.



On Wed, Apr 16, 2014 at 8:21 AM, <edgar.soldin@xxxxxx> wrote:

> that's the way it's always been ;(
>
> anyway, most modern backends are thin wrappers around complex API libs,
> which even dare to change overtime. so much for writing emulation stubs
> just once and use them forever.
>
> ..ede
>
> On 16.04.2014 15:16, Michael Terry wrote:
> > Well, without having mocks from new backend devs, we are in the position
> of accepting code that we can't test and thus can't edit with safety.
> >
> >
> > On 16 April 2014 09:09, <edgar.soldin@xxxxxx <mailto:edgar.soldin@xxxxxx>>
> wrote:
> >
> >     but who's gonna hack the "emulator"? we barely provide for duplicity
> as it is. demanding one from backend dev's might discourage early on!
> >
> >     ..ede
> >
> >     On 16.04.2014 14:49, Michael Terry wrote:
> >     > Well, for python libraries that the backends use, I imagine we can
> provide a fake version of that library.  So we never have to have an
> account or hit the network.
> >     > -mt
> >     >
> >     >
> >     > On 16 April 2014 04:28, <edgar.soldin@xxxxxx <mailto:
> edgar.soldin@xxxxxx> <mailto:edgar.soldin@xxxxxx <mailto:
> edgar.soldin@xxxxxx>>> wrote:
> >     >
> >     >     On 15.04.2014 19:21, Michael Terry wrote:
> >     >     >
> >     >     > I'm particularly interested in thinking about ways to mock
> the remote services needed by the backends.
> >     >
> >     >     totally clueless here.. i see no way that we keep/have backend
> libraries on the test machine and simulate an actual backend or even access
> a real backend account!
> >     >
> >     >     only way i can imagine it that we deal with backend testing
> within the confines of duplicity. backends could contain triggers to
> simulate errors ( specific error codes, broken connections ) but i wonder
> if that's worth the effort. maybe we should stop at testing backend.py
> after all.
> >     >
> >     >     some quick thought ..ede/duply.net <http://duply.net> <
> http://duply.net>
> >     >
> >     >     _______________________________________________
> >     >     Mailing list: https://launchpad.net/~duplicity-team <
> https://launchpad.net/%7Eduplicity-team> <
> https://launchpad.net/%7Eduplicity-team>
> >     >     Post to     : duplicity-team@xxxxxxxxxxxxxxxxxxx <mailto:
> duplicity-team@xxxxxxxxxxxxxxxxxxx> <mailto:
> duplicity-team@xxxxxxxxxxxxxxxxxxx <mailto:
> duplicity-team@xxxxxxxxxxxxxxxxxxx>>
> >     >     Unsubscribe : https://launchpad.net/~duplicity-team <
> https://launchpad.net/%7Eduplicity-team> <
> https://launchpad.net/%7Eduplicity-team>
> >     >     More help   : https://help.launchpad.net/ListHelp
> >     >
> >     >
> >
> >     _______________________________________________
> >     Mailing list: https://launchpad.net/~duplicity-team <
> https://launchpad.net/%7Eduplicity-team>
> >     Post to     : duplicity-team@xxxxxxxxxxxxxxxxxxx <mailto:
> duplicity-team@xxxxxxxxxxxxxxxxxxx>
> >     Unsubscribe : https://launchpad.net/~duplicity-team <
> https://launchpad.net/%7Eduplicity-team>
> >     More help   : https://help.launchpad.net/ListHelp
> >
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~duplicity-team
> Post to     : duplicity-team@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~duplicity-team
> More help   : https://help.launchpad.net/ListHelp
>