Many projects have release notes that include the names of people that contributed to the release. Who reads these names? Well, at the very least, the people in that list read the names. Fozzie: Nobody reads those names anyway, do they? Kermit: Sure. They all have families. – The Great Muppet Caper If your project doesn’t do this, I think it should. My name was listed in a release notice today. I’ll share the details, and try to point out why saying thanks to contributors is a good idea. ...

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. This is handy in lots of places, and avoids having to wrap things in try/except blocks. ...

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 ? a : b PHP test ? a : b Ruby test ? a : b Did I forget some language? probably Python a if test else b Why?? Why?? Ok. Now that I’ve written this post, I’ll remember it. ...

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. (error cases omitted). ...

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. unittest Specify moduleName.className, like so: ...

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. Test fixtures are the resources and initial conditions that a test needs to operate correctly and independently from other tests. The phrase has also grown to mean the functions and methods that are used to do that resource and environment handling. ...

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