Dag Odenhall

With the new `attest` command it isn't obvious how to measure coverage. These should work: ``` coverage run -mattest coverage run $(which attest) ``` These solutions should be documented as...

You are quite right, I noticed this too. The coverage docs claim -m is supposed to work but I get the same error. It does however work fine if you...

[This issue is now resolved upstream in the latest coverage.py relase](https://bitbucket.org/ned/coveragepy/issue/95/run-subcommand-should-take-a-module-name).

The #105 equivalent would thus be something like, ``` python db = Tests(foreach=[memorydb, filedb]) @db.test def dbtest(conn): assert some_condition(using=conn) ``` The benefit becomes more obvious when the list of contexts...

Mainly left out so far because: - I'd like test functions to work correctly if called directly - Proper testing should ensure isolation I think But the latter is not...

Maybe we could have 'shared contexts' that keep track of the tests they surround, and only runs the setup the first time we 'enter', and the teardown when all tracked...

…except it wont work for running individual tests by calling, if not all tests in the collection are run. The teardown would never run. Exit handlers could be used to...

Could we make it work nicely with logs coming from code run during a test? If a terminal output handler is used, printing would be delayed until after the test,...

This is intentional. It seems more useful to me in for example: ``` assert isinstance(a, float) ``` to get ``` not isinstance(1, float) ``` rather than ``` not False ```...

Do you think it sufficient to evaluate in only two steps, and not evaluate nested calls recursively? That'd be less noisy. Complicated nesting in a one-liner doesn't seem very Pythonic...