3 ms·

I'm pretty fastidious about following TDD practices, and I am very careful to cover as much program state as the language I'm using reasonably allows. However,

I'm pretty fastidious about following TDD practices, and I am very careful to cover as much program state as the language I'm using reasonably allows. However, my mental model for approaching TDD I think is much simpler than the approach presented here. It basically is: Do I _really_ understand the design implications of the unit I'm about to develop? - No: Play around and prototype, and learn about my design, don't worry about tests - Yes: Throw away any prototype and then really do the unit test-first. I found that I gravitated towards this process after I learned (partly thanks to blogs from Uncle Bob Martin) that unit tests are really formal design specs. They are so formal and specific that they are expressed in code- a program describing what your program does. Before you can write one of those (or as many as your unit needs), you need to have a very precise concept of how you are about to proceed, and what exactly the product code is about to do. The benefit of this process is that I prefetch a really deep understanding of the system I'm building. This leads to less bugs, and it leads to sensible, well-documented, and meaningful tests. It just takes a bit of discipline to follow at first, when you're not used to working this way. Some argue that it takes longer to write code this way, especially when I throw away my hard-earned working prototype! It does take a little longer at first, but: - Once I know the answer/outcome I seek, the tested version comes out way faster than the prototype. - I spend much less time later on fixing my own bugs, which I learned are mostly due to my own lack of understanding the full dimensions of my system's design.

waterlink 10y ago
This is a pretty interesting process you have there. I usually use throw-away Prototypes/Spikes, when I do not know how to write my first test or I feel uncomfortable test-driving the problem. Once I reach enough confidence, I remove spike's code and start test-driving it. I let the design of the system emerge on its own, while I'm listening to how hard it is to write tests and steering the wheel using Red-Green-Refactor (2nd cycle of TDD) and while I'm following Specific/Generic rule (applying Triangulation together with Transformation Priority Premise) (this is the 3rd cycle of TDD). Red-Green-Refactor on its own indeed is very well known for leading quickly to the local maximum of the solution and its design. 3rd Cycle of TDD breaks out of the local maximum of the solution to the problem. 4th cycle of TDD breaks out of the design maximum (4th cycle of TDD - Hourly, we step back and look at the overall design and architecture of the system, taking a careful look at the architectural boundaries and seeing if we are about to cross any of them with our efforts, we proceed with informed decisions steering to the right design we want for the next hour). Here is the Robert C. Martin's blog post on the cycles of TDD: http://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html http://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfT...

waterlink 10y ago

This is a pretty interesting process you have there. I usually use throw-away Prototypes/Spikes, when I do not know how to write my first test or I feel uncomfortable test-driving the problem. Once I reach enough confidence, I remove spike's code and start test-driving it. I let the design of the system emerge on its own, while I'm listening to how hard it is to write tests and steering the wheel using Red-Green-Refactor (2nd cycle of TDD) and while I'm following Specific/Generic rule (applying Triangulation together with Transformation Priority Premise) (this is the 3rd cycle of TDD). Red-Green-Refactor on its own indeed is very well known for leading quickly to the local maximum of the solution and its design. 3rd Cycle of TDD breaks out of the local maximum of the solution to the problem. 4th cycle of TDD breaks out of the design maximum (4th cycle of TDD - Hourly, we step back and look at the overall design and architecture of the system, taking a careful look at the architectural boundaries and seeing if we are about to cross any of them with our efforts, we proceed with informed decisions steering to the right design we want for the next hour). Here is the Robert C. Martin's blog post on the cycles of TDD: http://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html http://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfT...