There's some absolute nonsense in the TDD style. Exposing internal details for test is recommended and bad for non-test users of the interface. Only testing thr

There's some absolute nonsense in the TDD style. Exposing internal details for test is recommended and bad for non-test users of the interface. Only testing through the interface (kind of the same as above) means tests contort to hit the edge cases or miss them entirely. The whole interface hazard evaporates if you write the tests in the same scope as the implementation, so the tests can access internals directly without changing the interface. E.g. put them in the same translation unit for C++. Have separate source files only containing API tests as well if you like. Weird that's so unpopular. There's also a strong synergy with design by contract, especially for data structures. Put (expensive) pre/post and invariants on the methods, then hit the edge cases from unit tests, and fuzz the thing for good measure. You get exactly the public API you want plus great assurance that the structure works, provided you don't change semantics when disabling the contract checks.