On Sun, Nov 29, 2020 at 8:49 PM Brian Theado <[email protected]> wrote:
> Having measurable code coverage of the automated tests will be useful. > > The coverage.py library is not at all tied to pytest. > I had forgotten that. The big picture: Leo's old unit-testing framework, based on @test nodes in unitTest.leo, is inflexible. To add new features, complex code must be added to leoTest.py. In contrast, leoTest2.py contains only a few simple classes, subclasses of unittest.TestCase. I am about to simplify the code further, by adding top-level helper functions in leoTest2.py, for use by various setUp methods. This may reduce or eliminate the need for base classes. To emphasize: leoTest2.py has *easy* access to all of the features of python's unittest module, and by extension, all of the features of pytest, nose, whatever. This is the real breakthrough. About a year ago I tried running its standalone version against Leo's > existing tests. > > However, some of the coverage results were not making sense. Possibly the > way leo's unit test framework loads the code was causing confusion to > coverage.py. I didn't do any investigation to see if that is a reasonable > guess. > All such problems should go away, possibly to be replaced by new complications :-) For example, there is the question of how to init g.app only once for a suite of tests. Googling this yields several useful leads involving per-class and per-module *fixtures*. I'm still wrapping my head around this. All this to say that your planned approach of extracting the tests into > standard pytests is probably the better path to reliable code coverage > measurements. > I agree. Yesterday's work completely proves the concept. I'll say more in a new post. Have you considered using pytest features such as fixtures and > parameterized marks? > Not yet :-) My present plan is to create test *functions* with a single test class, rather than creating separate test *classes.* This seems like the simplest thing that could possibly work. While I was debugging the new code I switched back and forth between running the test class with unittest and with pytest. For debugging, unittest seems a bit better. So I don't necessarily want to tie the code to pytest features. Unless they add something essential. I tend to favor composition over inheritance and functions over classes. > The fixture feature helps with this preference. > In the present environment, the difference seems small. However, this comment nudged me towards creating top-level helper functions in leoTest2.py. That seems like a step forward. I think your preference is the opposite, but I thought I'd ask. > I don't have a strong preference at present. Many thanks for all your comments. They have been helpful. 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAMF8tS17yh%2BeV8sywhotBbBH_7UhF1rP%3Do9p-H3_%3D-BhUfO8cA%40mail.gmail.com.
