Various releases

Recently I’ve been working on the Python unittest API in my spare time, with a long term goal of making it possible to safely and sensibly glue many different plugins together into the core.

Two important components of that goal are being able to extend the data included in a test result, and being able to change how a test is run (such as adding new exceptions that should be treated as specific outcomes – python unittest uses exceptions to signal outcomes).

In testtools 0.9.2 we have an answer to both those issues. I’m really happy with the data included in outcomes API, ‘TestCase.addDetail’. The API for extending outcomes works, but only addresses part of that issue for now.

Subunit 0.0.4, which is available for older Ubuntu releases in the Subunit releases PPA now, and mostly built on Debian (so it will propogate through to Lucid in due course) has support for the addDetail API. Subunit now depends on testtools, reducing the non-protocol related code and generally making things simpler.

Using those two together, bzr’s parallelised test suite has been improved as well, allowing it to include the log file for tests run in separate processes (previously it was silently discarded). The branch to do this will be merged soon, its just waiting on some sysadmin love to get these new versions into its merge-test environment. This change also provides complete capturing of the log when users want to supply a subunit log containing failed tests. The python code to do this is pretty simple:

def setUp(self):
    super(TestCase, self).setUp()
    self.addDetail("log", content.Content(content.ContentType("text", "plain",
        {"charset": "utf8"}), lambda:[self._get_log(keep_log_file=True)]))

I’ve made a couple of point releases to python-junitxml recently, fixing some minor bugs. I need to figure out how to add the extra data that addDetails permits  to the xml output. I suspect its a strict superset and so I’ll have to filter stuff down. If anyone knows about similar extensions done to junit’s XML format before, please leave a comment 🙂


4 thoughts on “Various releases

  1. No, its one function call.

    Breaking it down:
    # unittest boilerplate to apply a setup to everything in a test case class
    def setUp(self):
    super(TestCase, self).setUp()

    # add a detail called ‘log’, which is utf8, and which gets its content from
    # self._get_log(keep_log_file=True)
    self.addDetail(“log”, content.Content(content.ContentType(“text”, “plain”,
    {“charset”: “utf8”}), lambda:[self._get_log(keep_log_file=True)]))

  2. Any particular reason why

    self.addDetail(“log”, self._get_log(keep_log_file=True),

    wouldn’t have done as well? You say it’s “one function call”, but I also see an instantiation of two custom objects, a dictionary with properties, a lambda and a list. I would hate to remember all that when I was otherwise busy debugging a test failure and decided to add extra log info.

  3. Objects don’t require parsers all over the place: using a basic string would allow for all sorts of mistakes (have seen them before). Ideally I would have been able to grab mime support from the stdlibrary mail routines, but they were too tightly coupled to sending mail (which also explains why the http module rolls quite so much of its own).

    I am open to this being changed of course – the reason its in testtools and not Python’s stdlib [yet] is to see how well it works. I do suggest you give it a try before binning it ;). I have found it nice to work with. The expected idiom is that you’d setup all the extra info all the time, so that when you’re debugging its just there, ready for you.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s