[Python-ideas] Why is design-by-contracts not widely adopted?

Marko Ristin-Kaufmann marko.ristin at gmail.com
Mon Oct 8 11:04:27 EDT 2018


Hi Chris,

I hope you don't mind me responding though you would like to stop
participating. This message is meant for other readers in case they are
interested.

> Alice tests her package A with some test data D_A. Now assume Betty did
> not write any contracts for her package B. When Alice tests her package,
> she is actually making an integration test. While she controls the inputs
> to B from A, she can only observe the results from B, but not whether they
> are correct by coincidence or B did its job correctly. Let's denote D'_B
> the data that is given to B from her original test data D_A during Alice's
> integration testing.
> >
>
> If you're regularly changing your function contracts, such that you
> need to continually test  in case something in the other package
> changed, then yes, that's exactly what I'm talking about.
>

The user story I put above had nothing to do with change. I was telling how
manually performing integration tests between A and B is tedious for us
(since it involves some form or the other of manual recording of
input/outputs to the module B and adapting unit tests of B) while contracts
are much better (*for us*) since they incur little overhead (write them
once for B, anybody runs them automatically).

I did not want to highlight the *change* in my user story, but the ease of
integration tests with contracts. If it were not for contracts, we would
have never performed them.

Cheers,
Marko



On Mon, 8 Oct 2018 at 16:22, Chris Angelico <rosuav at gmail.com> wrote:

> On Mon, Oct 8, 2018 at 11:11 PM Steven D'Aprano <steve at pearwood.info>
> wrote:
> >
> > On Mon, Oct 08, 2018 at 09:32:23PM +1100, Chris Angelico wrote:
> > > On Mon, Oct 8, 2018 at 9:26 PM Steven D'Aprano <steve at pearwood.info>
> wrote:
> > > > > In other words, you change the *public interface* of your functions
> > > > > all the time? How do you not have massive breakage all the time?
> > > >
> > > > I can't comment about Marko's actual use-case, but *in general*
> > > > contracts are aimed at application *internal* interfaces, not so much
> > > > library *public* interfaces.
> > >
> > > Yet we keep having use-cases shown to us involving one person with one
> > > module, and another person with another module, and the interaction
> > > between the two.
> >
> > Do we? I haven't noticed anything that matches that description,
> > although I admit I haven't read every single post in these threads
> > religiously.
>
> Try this:
>
> On Mon, Oct 8, 2018 at 5:11 PM Marko Ristin-Kaufmann
> <marko.ristin at gmail.com> wrote:
> > Alice tests her package A with some test data D_A. Now assume Betty did
> not write any contracts for her package B. When Alice tests her package,
> she is actually making an integration test. While she controls the inputs
> to B from A, she can only observe the results from B, but not whether they
> are correct by coincidence or B did its job correctly. Let's denote D'_B
> the data that is given to B from her original test data D_A during Alice's
> integration testing.
> >
>
> If you're regularly changing your function contracts, such that you
> need to continually test  in case something in the other package
> changed, then yes, that's exactly what I'm talking about.
>
> I'm tired of debating this. Have fun. If you love contracts so much,
> marry them. I'm not interested in using them, because nothing in any
> of these threads has shown me any good use-cases that aren't just
> highlighting bad coding practices.
>
> ChrisA
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20181008/8781d506/attachment-0001.html>


More information about the Python-ideas mailing list