3 ms·

I think about unit testing like “pouring cement around your house of cards”. If you are good at unit testing you can turn your brain off and the tests write th

I think about unit testing like “pouring cement around your house of cards”. If you are good at unit testing you can turn your brain off and the tests write themselves. It’s about preserving any method chain call flows and preserving the integrity of anything that is parsing something, like a Regex or whatever. Focus on testing after you have built a nice little house of cards... it will make it harder for another dev to come along and blow it over in the future.

commandlinefan 5y ago
> pouring cement around your house of cards I've observed that way too much unit testing ends up having this effect, but it doesn't have to. There are two extremes with unit testing: "no unit testing at all" and "mock everything", and both are wrong for different reasons. I have yet to see a codebase with no unit testing which doesn't have problems (in production that impact real users) that could easily have been caught by a simple unit test. The mock-everything approach ensures that you can never make a change to the code, though. A simple middle-ground is to mock everything that's actually external to the system being tested: databases, file systems, remote services. Otherwise, use the actual code: if a function calls another function, internal to the system being tested, just call that function (but make sure it has a unit test of its own).
- pydry 5y ago
  >I have yet to see a codebase with no unit testing which doesn't have problems I've seen many code bases work much better with a bundle of integration tests and no unit tests. IMHO tests which hit a real database are always more useful than ones that mock it out.