[TIP] Testing a daemon with coverage (nose)

[Ben Finney]

Laura Creighton <lac at openend.se> writes:

> Remember that this subthread started when you asked why anybody would
> be interersted in py.test --looponfailing behaviour. Py.test was made
> in conjunction with py.py to test our python compiler, which was, in
> its very early days, about 10,000 times slower than CPython.
[…]

Thanks, this is indeed a reason why well-designed and loosely-coupled
code would nevertheless have slow-running unit tests. This is a good
argument for wanting to run only part of a unit test suite.

> It is interesting that you want tofind out if a new piece of code
> broke an existing test as soon as possible. I don't. Because in the
> world that I work in, when I run a new test run, and some old test
> that I wasn't expecting to break, breaks, the most common reason is --
> somebody else made a checkin which broke that test.

Heh. I find, instead, that a common reason for breaking tests that
previously worked is that my current local design conflicts with
assumptions (or even explicit decisions) made elsewhere; which is
exactly what the existing unit tests are intended to tell me. I'd much
rather know that early so my local design can be corrected before I
build further on a flawed design.

-- 
 \      “There's a fine line between fishing and standing on the shore |
  `\                            looking like an idiot.” —Steven Wright |
_o__)                                                                  |
Ben Finney