Delgan

Yeah, you are right, this can be useful to avoid some mistakes. I need to see how well it integrates. For example, here: [`tests/test_datetime.py#L81`](https://codecov.io/gh/Delgan/loguru/src/3baa50121db1d53d5eb330d539966b9b444389aa/tests/test_datetime.py#L81) The line is never executed but...

> Regarding the test example, you could use an assert for the attribute name and raise AttributeError always? Given the extra assertion this would improve the test. Sorry, I struggle...

> Then it appears to just be a matter of the other attributes not being tested/covered, isn't it? Yes, but theorically, others attributes doesn't need to be tested. They are...

Nice trick. I will update your branch when I have some time.

I changed my mind again. As explained in [this StackOverflow comment](https://stackoverflow.com/questions/1628996/is-it-possible-exclude-test-directories-from-coverage-py-reports#comment76661774_1629194), I think coverage is not the appropriate tool to detect problems in the test suite. My trouble with this:...

Thanks for taking the time to answer my concerns. I understand and I see how this can be useful. I'm interested in integrating it to the CI, but this should...

Oops, I played with the Travis webhook the other day, it seems I broke it. I updated the settings so that PR should trigger the CI tests. I could not...

@blueyed Sorry, I missed your comments. Thanks for the hard work. It's ok if some branches in the tests are not covered. As I said, I don't plan to make...

Hey @blueyed. So, with these changes, coverage of the project is no longer checked? That's problematic. :/ It seems to me that we are moving away from the primary purpose...

> I do not think that is really possible without using coverage. I don't understand. How does using `coverage` relate to writing a custom `pytest` plugin checking called functions? >...