4 ms·

While I agree that a good architecture cannot be derived from (unit-)tests alone, tests do indeed help a lot with good design. As soon as you need elaborate se

by qayxc 5y ago

While I agree that a good architecture cannot be derived from (unit-)tests alone, tests do indeed help a lot with good design. As soon as you need elaborate setup in order to test a single piece of functionality (or function), you will start to rethink your design. In such cases there's too much coupling, too many dependencies, or too many responsibilities within the function under test. Seeing tests as separate from implementation and design is a much bigger issue IMHO. TDD only provides value as opposed to overhead, if you understand it as an integral part of the design and implementation process and use them with that in mind.

sorokod 5y ago
That last sentence seems to do a lot of heavy lifting. Where does it fit in the red-green-refactor mantra?
- qayxc 5y ago
  Red-green-refactoring doesn't work if you are dealing with existing software, for example (unless there's a well-documented and -understood defect). It's not TDD (emphasis of the "driven"-part) if tests are only used to confirm already implemented behaviour. I found that especially in larger organisations there's all too often hard requirements for unit tests and high test coverage. This doesn't work as intended, though, if the team doesn't "live" by the TDD concept and unit tests are only there to check some box on a "best practices" list. IMO it's perfectly fine to only use TDD for some components of an application and rely on integration- and acceptance tests only for others. Glue code and cross-cutting components don't benefit from TDD. An external API or component that you don't control can also prevent meaningful unit tests and force certain design decisions, rendering TDD an exercise in writing (and maintaining) mocks, etc. What I tried to express is that TDD is one tool of many and not always the best choice; especially so when it is tacked onto an existing process that doesn't use it as intended or cannot benefit from it.

by qayxc 5y ago

sorokod 5y ago

That last sentence seems to do a lot of heavy lifting. Where does it fit in the red-green-refactor mantra?

qayxc 5y ago
Red-green-refactoring doesn't work if you are dealing with existing software, for example (unless there's a well-documented and -understood defect). It's not TDD (emphasis of the "driven"-part) if tests are only used to confirm already implemented behaviour. I found that especially in larger organisations there's all too often hard requirements for unit tests and high test coverage. This doesn't work as intended, though, if the team doesn't "live" by the TDD concept and unit tests are only there to check some box on a "best practices" list. IMO it's perfectly fine to only use TDD for some components of an application and rely on integration- and acceptance tests only for others. Glue code and cross-cutting components don't benefit from TDD. An external API or component that you don't control can also prevent meaningful unit tests and force certain design decisions, rendering TDD an exercise in writing (and maintaining) mocks, etc. What I tried to express is that TDD is one tool of many and not always the best choice; especially so when it is tacked onto an existing process that doesn't use it as intended or cannot benefit from it.