On Fri, Jan 10, 2020 at 8:33 AM Edward K. Ream <edream...@gmail.com> wrote:
> > I still think full line-by-line coverage analysis will be very valuable. >> >> I agree. I have just created #1474 >> <https://github.com/leo-editor/leo-editor/issues/1474> for this. >> > > Many thanks for suggesting this. `pytest --cov` has quickly become one of > my favorite tools, on a par with pyflakes and pylint. > Excellent. I'm glad it is helpful. pytest is easy to configure, and it's easy to suppress coverage test within > the code itself. leo-editor/.coveragerc now contains the default settings. > I was unaware of that feature. Looks useful. I have doubts about the following entries you are suppressing: assert, except, raise. For all 3, it seems like a case-by-case "pragma: no cover" is better than wholesale suppression. Especially assert. In general, an assert will precede other code you will already want cover with tests, so why suppress the coverage report from the assert statement itself? With except and raise there might be some cases in which the code can't be hit unless there is a bug in your library code. Since you can't anticipate your bugs, you would want to suppress those from the coverage report. But in most cases, I expect the exception catching and raising will be for cases in which the user passes in bad data. It would be valuable to exercise that code in unit tests to ensure it works the way you expect if a user encounters it. So my 2 cents says it would be better to have case-by-case suppression for the exceptions catching and raising whose purpose is to alert you to bugs in your own code. Brian -- 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/CAO5X8CzCwRF2%3DsiiXOGBJ8F_tgGHEnSnY3DXbz2GA9h2KQEBYg%40mail.gmail.com.
