[mattvanhorn]

I agree with the general approach suggested in the article (in tests, write/assume the code you wish you had).

But one detail ran counter to my personal practice.

I don't believe that "symmetrical" unit tests are a worthy goal. I believe in testing units of behavior, whether or not they correspond to a method/class. Symmetry leads to brittleness. I refactor as much as possible into private methods, but I leave my tests (mostly) alone. I generally try to have a decent set of acceptance tests, too.

Ideally, you specify a lot of behavior about your public API, but the details are handled in small private methods that are free to change without affecting your tests.

[searls]

I understand the concern, but I value consistency and discoverability, so symmetry of thing-being-tested to test itself is (so far) the best way I've found to make sure it's dreadfully obvious where a given unit's test is.

This approach is not concerned with brittleness or being coupled to the implementation because each unit is so small that it's easier to trash the object and its test when requirements change than it is to try to update both dramatically.

[mattvanhorn]

I suppose that if you do keep things that small, it could work well to trash and rewrite. Plus it has the benefit of making you consider explicitly what is going/staying.

Personally, I like my tests to be pretty clearly about the behavior of the contract, and not the implementation, which is hard when you require every method have a test.

I'd also be concerned that other team members are reluctant to delete tests - as this is a dysfunction I see often, and try to counteract with varying degrees of success.

[radicalbyte]

Symmetrical tests really help other developers on your team. It depends on your design, but "public API" tests are often something between integration and unit tests - i.e. they tests in-process co-operation of units.