I’m going to cover nose setup and teardown fixtures at the package, module, class, method, and function level. This isn’t about what code to put into the fixtures, just about the syntax and flow. And a bit about naming conventions. ...

You can’t use getattr() to look stuff up in a dictionary. But the ‘default’ feature of getattr() is so useful. What’s the dict way to do the same thing? This is one of those posts that I’m writing because I keep having to look it up. So if I write it, I’ll remember it. Hopefully. getattr I’ve been using the ‘default’ parameter to getattr for some time, and it’s super handy....

The ternary operator is a way to concisely say: “If test, then a, else b“, with the value of the statement being the value of a or b. language how to say it C test ? a : b C++ test ? a : b javaScript test ? a : b Perl (not perl 6) test ?...

As with nose, I ran pytest on the tests written to demonstrate unittest fixtures. Some surprises. There are some differences, which I’ll list out in this post. Before we get started, I’d like to express that I’m a huge fan of pytest. The cool stuff in pytest far outweighs any invonvenience that it doesn’t behave exactly like unittest. However, it’s good to know what the differences are, so you can be informed about how your unittests will run under pytest. ...

I ran nosetests on the tests written for unittest from my unittest fixture post. No surprises. Nose supports unittest style fixtures: module: setUpModule()/tearDownModule() class: setUpClass()/tearDownClass() around methods: setUp()/tearDown() add cleanup functions: addCleanup() called from setUp() and from a test skipping tests dynamically: testSkip() called from setUp() error conditions: don’t run the test or the matching tearDown if setUp fails. This is true for module, class, and method fixtures. Here’s the output....

I’ve got the test code from my unittest fixture syntax and flow reference, and I want to try to run one class, say TestSkip from unittest, nosetests, and pytest, to compare the the control flow. Therefore, I need for each framework: The option to make it as quiet as possible (-q for all of them) The option to turn off output capture (-s works for both pytest and nose, not needed for unittest) The way to call an individual class (this is where they all differ....

In unittest fixture syntax and flow reference, I only presented fixture methods and functions that threw no exceptions. However, in real production code, it is entirely possible for something to go wrong when setting up test fixtures. This post is simply do demonstrate exactly what happens to the flow of your test code when an exception is thrown in a fixture function. And, while I’m at it, I may as well demo the normal control flow when a test fails, asserts, or throws an exception....

This post contains examples of how unittest test fixture functions and methods are written, and in what order they run. It may seem like a long post, but it’s mostly code examples and example output. I want this to be a useful reference for both the syntax and flow of unittest fixtures. If I missed something, please comment below, and I’ll update the post. Intro: Software Test Fixtures The term test fixtures really means two things....

pip pip is hands down my favorite way to install stuff in Python. If you need to use it behind a firewall, download ...

or Complete coverage testing or More is Better testing The setup For the sake of this post, let’s say I’ve got a Python package that needs testing. It’s written completely in Python It has a specification fully describing the API The specification is so complete that it also covers behaviors and side effects The API is the only interface this program exposes It was written by us It was written recently It only uses base Python Therefore:...