Posts Tagged ‘unittest’

Subunit V2 is coming along very well. Current status: I have a complete implementation of the StreamResult API up as a patch for testtools. Thats 2K LOC including comeprehensive tests. Similarly, I have an implementation of a StreamResult parser and emitter for subunit. Thats 1K new LOC including comprehensive tests, and another 500 lines of […]


StreamResult, covered in my last few blog posts, has panned out pretty well. Until that is, that I sat down to do a serialised version of it. It became fairly clear that the wire protocol can be very simple – just one event type that has a bunch of optional fields – test ids, routing […]


My last two blog posts were largely about the needs of subunit, but a key result of any protocol is how easy working with it in a high level language is. In the weekend and evenings I’ve done an implementation of a new set of classes – StreamResult and friends – that provides: Adaption to […]


Of course, as happens sadly often, the scope creeps.. Additional pain points Zope’s test runner runs things that are not tests, but which users want to know about – ‘layers’. At the moment these are reported as individual tests, but this is problematic in a couple of ways. Firstly, the same ‘test’ runs on multiple […]


I recently added a formal interface to testrepository to enable cross-machine scaling of test runs. As testrepository is still a static scheduler, this isn’t perfect, but its quite a minimal interface, which makes it easy to implement. I will likely evolve it in reaction to feedback and experience. In the long term I’d love to […]


Tesetrepository has a really nice workflow for fixing a set of failing tests: Tell it about the failing tests (e.g. by doing a full test run, or running a single known failing test) Run just the known failing tests (testr run –failing) Make a change Goto step 2 As you fix up the tests testr […]


So a while back I blogged about maintainable test suites. One of the things I’ve been doing since is fiddling with the heart of the fixtures concept. To refresh your memory, I’m defining fixture as some basic state you want to reach as part of doing a test. For instance, when you’ve mocked out 2 […]


Looks like someone has come up with a nose plugin for subunit – excellent! http://www.liucougar.net/blog/projects/nose-subunit In their post the author notes that subunit is not easy_installable at the moment. It will be shortly. Thanks to Tres Seaver there is a setup.py for the python component of Subunit, and he has offered to maintain that going forward. […]


There’s a test code maintenance issue I’ve been grappling with, and watching others grapple with for a while now. I’ve blogged about some infrastructural things related to it before, but now I think its time to talk about the problem itself. The problem shows up as soon as you start writing setUp functions, or custom […]


For a while now I’ve been using subunit as part of my regular development workflow. I would pipe test results to a file, use subunit to report on failures from that file, and be able to inspect all the failures at my leisure without rerunning tests or copy and pasting from far back in my […]



Follow

Get every new post delivered to your Inbox.

Join 877 other followers