4 ms·
If you write your tests first (TDD), your "complex business object setup" (aka state setup) invariably gets simpler. The more complex your code, the more coupl
by lectrick 13y ago
If you write your tests first (TDD), your "complex business object setup" (aka state setup) invariably gets simpler.
The more complex your code, the more coupling there is, the more sources of bugs there are potentially... and the harder it is to write tests for that code.
Break down your code into smaller methods and more focused objects and just watch your unit tests get simpler.
- jasonlotito 13y agoPeople tend to forget that TDD isn't a 3-step process. Even this article makes that mistake. Write a test, pass that test, refactor. People generally forget the refactoring step. Basically though, if you find your test difficult to write, there is a problem, and it's not with the test. And that should be your sign that you either don't understand the problem, or you are trying to do too much. Now, this is hard. It's hard to accept that way of thinking. But the end result has always been cleaner, better code in my experience. It's not always the obvious way, but it's the best way.
- mercurial 13y agoI'm not convinced, for a couple of reasons. I haven't found unit testing to help in any way with the complexity of business objects, which are often more-or-less dumb beans. When you are handling complex problems, you are going to end up with complex data structures. Unit testing can help with modularizing services, though. The second problem is that whenever you're faced with a large, older codebase, it's often difficult or impossible to refactor away complexity in core components.