pylint-unittest plugin to detect less than optimal usage of assertions in your unittest usage
Hello, I wrote a Pylint plugin to detect less than optimal usage of unittest assertions, for example writing self.assertEqual(x, None) instead of self.assertIsNone(x) or using deprecated aliases. It's published in PyPI under the name pylint-unittest and is also available on GitHub here: https://github.com/federicobond/pylint-unittest I would love to hear your feedback on it. Also, it took me longer than I expected to put together the necessary boilerplate for doing test-driven development on this plugin, so I hope it can serve as a good base for others too. I feel that the way pylint-django tests are structured is too awkward for newcomers. Thank you! Federico
Hi Federico, This looks like an interesting plugin - thanks for sharing! It's great to see tools that aim to improve the quality of tests (over and above regular linting). Personally, I've moved away from Unittest to pytest so this plugin is not so relevant for my usual testing work. __But__ (as a bit of a TDD nut) I'm interested to know more about some of the issues you found getting TDD up and running for your build of the plugin... Could you share what aspects took you longer than expected or were problematic? Are there any places where you think community effort could be directed to help more people create plugins? Cheers, James On Tue, 26 Jun 2018, at 11:15 PM, Federico Bond wrote:
Hello,
I wrote a Pylint plugin to detect less than optimal usage of unittest assertions, for example writing self.assertEqual(x, None) instead of self.assertIsNone(x) or using deprecated aliases. It's published in PyPI under the name pylint-unittest and is also available on GitHub here:
https://github.com/federicobond/pylint-unittest
I would love to hear your feedback on it. Also, it took me longer than I expected to put together the necessary boilerplate for doing test-driven development on this plugin, so I hope it can serve as a good base for others too. I feel that the way pylint-django tests are structured is too awkward for newcomers.
Thank you!
Federico _______________________________________________ code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality
Thanks James! From what I recall, one thing that tripped me up is that pytest is never mentioned in the docs for writing a checker/plugin, despite being required by the Pylint test framework. But mostly it was the lack of examples for how to set everything up beyond what's mentioned in the docs. A clean boilerplate for pylint plugin development would have come super handy, because pylint-django does things quite differently. On Mon, Jul 16, 2018 at 5:30 PM James Cooke <me@jamescooke.info> wrote:
Hi Federico,
This looks like an interesting plugin - thanks for sharing! It's great to see tools that aim to improve the quality of tests (over and above regular linting).
Personally, I've moved away from Unittest to pytest so this plugin is not so relevant for my usual testing work. __But__ (as a bit of a TDD nut) I'm interested to know more about some of the issues you found getting TDD up and running for your build of the plugin... Could you share what aspects took you longer than expected or were problematic? Are there any places where you think community effort could be directed to help more people create plugins?
Cheers,
James
On Tue, 26 Jun 2018, at 11:15 PM, Federico Bond wrote:
Hello,
I wrote a Pylint plugin to detect less than optimal usage of unittest assertions, for example writing self.assertEqual(x, None) instead of self.assertIsNone(x) or using deprecated aliases. It's published in PyPI under the name pylint-unittest and is also available on GitHub here:
https://github.com/federicobond/pylint-unittest
I would love to hear your feedback on it. Also, it took me longer than I expected to put together the necessary boilerplate for doing test-driven development on this plugin, so I hope it can serve as a good base for others too. I feel that the way pylint-django tests are structured is too awkward for newcomers.
Thank you!
Federico _______________________________________________ code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality
participants (2)
-
Federico Bond
-
James Cooke