3 ms·
I've seen a lot of people say not to design code to be testable. That instead tests should work around whatever shape the code should be in "naturally". Writing
by iudqnolq 6y ago
I've seen a lot of people say not to design code to be testable. That instead tests should work around whatever shape the code should be in "naturally". Writing this out this seems stupid, it's been pretty influencial on how I code (for the past year or so, I'm a complete beginner).
- wccrawford 6y agoTo me, the shape the code should be is largely the same as easily-testable code anyhow. You want functions that do small, self-contained things so that you can reason about them efficiently. That also makes them easier to test. Yes, sometimes you end up with a monstrous function because of requirements... But then, that's how you have to test it anyhow. That said, some of the more intense testing things, like dependency injection, definitely change the shape of the code into abnormal forms. So I can agree there that it's adding complexity to the code that it shouldn't, just for testing. Some projects may warrant the increased complexity to trade for stability. I don't think most do.
- iudqnolq 6y agoSmall functions, sure. The most common case of this I've run into is should I use dependency injection just for testing. My function creates a Frob and interacts with it. By default Frobs persist changes to a DB and sync over the network. I don't want to do that in a test. Now I need to pass a frobFactory of (FrobConfig) -> Frob to my function. Sure in theory I could use my new configurability for all sorts of things, but in practice I only end up using the alternative path in tests. When do you not end up needing something like this?