Posts Tagged ‘testing’

Python 3 recently introduced a nice feature – subtests. When I was putting subunit version 2 together I tried to cater for this via a heuristic approach – permitting the already known requirement that some tests which are reported are not runnable be combined with substring matching to identify subtests. However that has panned out […]


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 […]


Subunit is seven and a half years old now – Conrad Parker and I first sketched it up at a CodeCon – camping and coding, a brilliant combination – in mid 2005. revno: 1 committer: Robert Collins <robertc@robertcollins.net> timestamp: Sat 2005-08-27 15:01:20 +1000 message:  design up a protocol with kfish It has proved remarkably resilient […]


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 […]


I’ve made the Testtools committers team own both the project and the trunk branch for both pyjunitxml and testscenarios. This removes me as a SPOF if anything needs doing in those projects – any Testtools committer can now do it. (Including code review and landing). If you are a testtools committer and need PyPI release […]


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 […]



Follow

Get every new post delivered to your Inbox.

Join 877 other followers