Hacker News Reader

Comment by mrisse | Hacker News Reader

Might one of the problems be that we place too much importance on the "symmetrical" unit test. In your example the child code is still covered when it is extracted from the parent.

As a developer that often prefers tests at the functional level, the primary benefit of tests for me is to get faster feedback while I am developing.

View on HN

The trouble with abandoning symmetrical unit tests is that:

* The unit is no longer portable and can't be pulled from the context it was first used in (e.g. into a library or another app) without becoming untested. And adding characterization testing later is usually more expensive * A developer who needs to make a change to that unit needs to know where to "test drive" that change from, which requires that they know where to look for the parent's test that uses it. That's hard enough but it completely falls over when the unit is used in two, three, or more places. Now a bunch of tests have to be redesigned and none of them are easy to find. * Integrated unit tests like this lead to superlinear build duration growth b/c they each get slower as the system gets bigger. This really trips teams up in year 2 or 3 of a system.

Unless I'm missing something, wouldn't the child dependency be enough to prevent the unit from being dropped into another library or app? That's a good point you bring up about knowing where to "test drive" the changes from, though usually on the apps I've worked on, they've been small enough that the relevant integration test could be found without much detective work.

I guess I haven't been involved in too many 2-3 year monolithic projects. Maybe that's when a stricter symmetrical unit test policy makes the most sense.

What other levels of tests do you end up running besides your unit tests? Do you have any integrated unit tests? Functional tests? End to end tests?

The author is stating that the child dependency cannot be extracted to another library or app. If it is extracted, it is untested, because the only tests wrapping the child dependency are actually testing the child's original parent. (Which is likely to not exist in whatever other library/app to which the child component is moved.) And then, to retroactively add tests to the child component in order to facilitate moving it to another library, is painful.

Having symmetrical tests enable components to be easier moved to other libraries/apps because the test can move with the unit under test.

Reply on news.ycombinator.com