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 <ros...@gmail.com> wrote: > On Mon, Oct 8, 2018 at 11:11 PM Steven D'Aprano <st...@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 <st...@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.ris...@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@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
