Agile Otter Blog

The basics are well-known: Everyone knows the basic cycle of TDD. You should also know the improved Industrial Logic version of the TDD cycle . You have heard Uncle Bob's three rules . But there is so much more to know. I have been gathering little sound bites for you which may help you build your skills and knowledge. Please feel free to drop additional factoids or questions. I'm happy to explain any of these at length if you like. Here is my list: Your code has two parts: the part you have covered with TDD, and the part that requires you to use a debugger. Microtests are F.I.R.S.T.   (you cannot TDD after writing the code) Only microtests are appropriate for TDD; other tests are useful, but not for TDD. Microtests are not all your tests - you need other levels of test still.  TDD does not validate your system; it only speeds development and improves quality. TDD without a pair programming partner is like programming while wearing only one shoe. ...

Today we didn't make a lot of linear progress I think of quality in two ways.  One is the product quality that users perceive, and the other is the habitability of the code itself. One says whether the function points and UX are well-selected, and the other says whether it is worth your time to try to work in the code.  One can have crap code that seems great externally, and one can have beautiful code that doesn't do anything a user is interested in doing (the popularly presented dichotomy). Likewise one could have poor functionality written poorly, or great functionality written well.  Those who consider themselves professionals in software craft will desire great functionally written well. I often get to work in code that started out as good functionality badly written. I get to work on the teams that clean up the mess and make the system more useful, scalable, and performant. As we work, the code gathers external quality. It becomes increasingly virtuous .  S...