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. ...

There is a relationship between how slow tests are and how much we interact with the tests while we are developing software. If the tests run instantaneously, I'll run them constantly. If the tests run in 30 seconds, I will run them 3 times in any 5 minute window of coding. If they run in 1 minute, I will run them 3-4 times per hour. If they run in 10 minutes, I will run them maybe 3 times a day. If they run in an hour, I'll run them 5 times a week at most. If they run for a day, I will almost never run them. If the build/test cycle is not incredibly fast, I will not participate in the code as fully and richly, instead falling back to rely on my IQ and memory and good intentions more. This is why tools like Infinitest for Java, sniffer for Python, autotest for ruby, and the like matter so much. It is also why there have to be build servers and test servers for any significant project. It is also why manu...

Dealing with product health is simple in theory. You need to have a central build-and-test server and a repo that is treated as the central repo for the developers (in git, servers have no built-in roles). It has to be set up to run all the tests, whether they are unit tests, story tests (cucumber, etc), or what-have you. Now, the thing you have to know is the state of your local machine, and the state of the build server. When I say GREEN , I mean "builds and all tests pass."   When I say RED  I mean that something doesn't build or did not pass all the tests. The Rules The rules in precedence order are: GET TO GREEN.   Green to green ; anything else is obscene. You need to know that your code is good, and the server's code is good, and you can push your code to the server. "But wait", you might say, "there are states unaccounted for here. What about pushing green to red?" "But Tim!" you may cry, "my code isn...

TDD is a pretty simple system, as popularly described.  For an individual doing a kata or playing with some example code it is really just three steps. On card #44 of AgileInAFlash it looks like this: It's the right way to think about TDD, and the right way to get started. When you get to a real project in a team environment you have many other issues to consider.  In a modern team environment, with a DVCS, it looks more like this: Get the current code ( git pull , get clone , hg pull -u , whatever) Run all the tests and be sure they're all really green, to avoid blaming yourself for unrelated breakages. If there are no tests, write a trivial failing test (" assertTrue(false) ") to prove your testing setup (ide, scripts, makefiles) really work. Then delete the trivial test. Write one "real" red test. INSIST ON RED. Write code to turn it green. Local commit "save your game" Refactor (or intentionally choose not to). Check to...

Just for the record: it is flat out impossible to "do the tdd" after the code is finished. This is just a matter of definition. You can write tests after the code is finished, but that has no relationship to TDD whatsoever. None. Nada. Zip. In TDD you write a new, failing test. Next you write enough code to pass the test. Then you refactor. This repeats until the code is done, writing and running tests continually. It shapes the way the code is written. It is a technique for making sure you write the right code, and that you do so in an incremental and iterative way. In ATDD, you have a failing acceptance tests. You take the first failing tests (or the easiest) and use TDD to build the code so that that part of the AT passes. You run the AT after each major step that you've built using TDD. When the AT is all green, you have completed the feature. This helps avoid early stop and also helps avoid gold-plating. If tests were product, then it would make no difference...

I'm working with Industrial Logic's newest Python album on microtesting (not yet released) and was lucky enough to get to test out the automated critique. So the way this eLearning works is that you download a problem to work on, and you're given tasks to perform. In this case, it's all about writing microtests for some simple python code. When you finish, you upload your results and an automated critique system digs through the code and gives you ratings and pointers. This is rather like having a mentor sitting with you, reviewing the code. I tell people that the eLearning here is something like they've never seen, but people think I'm marketing or something. Today I have a story for you: Yesterday I made a mistake and the automated critique busted me. The mistake was one where I constructed an object incorrectly and invalidated the premise of the test, yet I did this in such a way that the test passed for the wrong reason. I was feeling so sure I'd...