bitprophet/spec — Issue #11: Think about how to support per-method test groups
Author: bitprophet
Created: 2011-11-07 19:14:27+00:00
State: open

As usual, inspired by RSpec -- we can assert about class behavior, but what if we wanted to group tests more granularly, e.g. `Class.method should (x, y, z)`, there's no way to do that at the moment.

Syntactically it's a tough problem because we're not using nested blocks as in Ruby, but Python classes and methods.

----

One way to get 3 levels is to use modules differently than we do now: assert that if a module has classes in it, it's not the usual "module w/ functions" but a three-level setup where the module name, capitalized, is the class; classes are about methods (downcased I guess) and methods are the tests.

E.g., in `foo.py`:

```python
class MethodOne(object):
def accepts_xyz_parameters(self):
pass

class AnotherMethod(object);
def when_given_5_returns_10(self):
pass
```

Which might translate into this output:

```
Foo
.method_one:
- accepts xyz parameters
.another_method:
- when given 5 returns 10
````

(Actual indentation/formatting subject to change, of course -- just an example.)

This could be further enhanced, readability wise, by using lowercase class names so that no CamelCase to underscores conversion is required, though this then breaks with PEP8. Perhaps make that an option (i.e. perform CamelCaseConversion if required, and that's it.)

----

Think of other possible solutions too, though -- this could cause problems re: imports if one's actual app stores `Model` inside `model.py`, as then test module names match project module names. Though given a `tests/` folder which is not a package, imports need to go through actually-installed-on-PYTHONPATH names, and thus will typically be importing from a project package (i.e. `from myproject import model`), and so no actual conflict.