What are my tests telling me about my design

(Hosted by AvdiGrimm)

The idea of this session was to discover and catalog some of the ways tests tell us if our design is good or bad.

Here are some of the indications we came up with:

* Too many test cases per method: may indicate that the method is doing too much. We discussed the fact that complex business logic algorithms, with lots of special case, often appear to be atomic and indivisible; and thus only testable as a unit. But there is often a way to break them down into smaller pieces.

* Poorly factored edge cases: this is the case where there are many variations of input tested, when a few carefully-chosen edge cases would suffice. We discussed how this sometimes emerges when the algorithm under test has too many special cases, and the same result could be arrived at with a more general algorithm.

* Too much setup/teardown: indicates strong coupling in the class under test.

* Mocks returning mocks: can indicate that the method under test has too many collaborators.

* Poorly-named tests: sometimes means that the naming and/or design of the classes under test isn't sufficiently thought-out.

* Inheritance in test fixtures.

* Changing one thing breaks many tests: may just indicate bad factoring of tests, but can also indicate excess dependencies in the code.

* Mocks: some regard the use of mocks at all as a smell.

* Dynamic stubs (mocks with behaviour)

* Single test fixture per class?

* Too many dependencies that have to be included in the test context

* Referencing constants defined in the code under test for parameters or to check outputs: maybe those constants should be private.

* Primitive obsession (magic strings)

* Tests run slowly

* Temporal coupling - tests break when run in a different order: may just be a test smell; may be coupling in the code under test.

Blackboard capture: