On Fri, Mar 13, 2020 at 8:39 PM Brian Theado wrote: I came across these articles about pytest recently and thought they might > be of interest to other developers here. > > https://nedbatchelder.com/text/test3.html >
Thanks for the link. I'll take a close look. ...one quote I liked: > > "The kind of change I’m talking about here is refactoring your product > code so that your tests can get at the parts they want to. There’s nothing > wrong with using your testing as a way to challenge the modularity of your > code. Usually, improving the structure to benefit tests also ends up > helping you in other ways." > > Even better, in some cases the coverage reports encouraged me to eliminate code completely. The below two were linked from the above presentation: > > https://salmonmode.github.io/2019/03/29/building-good-tests.html > > This article also had some snips related to the quotes I already pasted > above (emphasis mine): > > "Testing code should not be difficult. *If the code is hard to test, then > the code is hard to use*. This is also indicative of tightly coupled > code." > > Hmm. leoAst.py is the kind of code that readily lends itself to unit testing. Otoh, Leo's Qt dock code depends on complex state set on program startup and shutdown, as well as arbitrary *sequences* of user actions. I agree that the code is hard to test and hard to use. That does not mean that testing that code will ever be easy. If anyone knows how to test the Qt code, I would appreciate knowing how. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAMF8tS2kKCv0WTGOmoSHb4uwRuHuGmc%3DhuJ-S_7mQENWVrV73Q%40mail.gmail.com.
