--- title: 'Internbot Chronicles #2' teaser: tags: playbook,apprenticeship author: Nick Quaranto published_on: 2009-03-30 --- [![''](http://farm4.static.flickr.com/3494/3301464736_3917159c6c_m.jpg)](http://www.flickr.com/photos/your_wht_knight/3301464736/) The past few weeks have been quite a lot of fun here in Boston. I gave a little talk on Git to some our training students, attended some fun [Boston.rb](http://bostonrb.org) events, hacked on some of thoughtbot's [open source projects](http://github.com/thoughtbot), and tested a lot. Yeah, a lot. I think I've spent more time writing actual test code than real code in the past 2-3 weeks. When testing first becomes a mode of development rather than a 'nice to have' or an afterthought, it's certainly jarring. So far it's been tough to learn and wrap my head around, but I believe in the long term the benefits are fantastic. I really do like the [Red, Green, Refactor](http://jamesshore.com/Blog/Red-Green-Refactor.html) cycle, and being around some other awesome developers who are doing this daily helps immensely. The process I've been going through in pair programming sessions and when I'm flying solo is usually this: 1. Create a new feature branch in Git. 1. [Write out the Cucumber feature](http://www.benmabey.com/2009/03/14/slides-from-outside-in-development-with-cucumber/) for whatever you're planning to do. 1. From here, if you're not sure what to do, spike for a while and toss that away once you're done. (Time boxing is nice for this, but I think throwing the code away is more important.) 1. If you find it necessary to write more than simple view or configuration code to make steps pass, drop down into functional/unit tests. Write a test, watch it fail. 1. Make it green with the actual implementation, and [only write enough code to make it pass](http://c2.com/cgi/wiki?YouArentGonnaNeedIt). 1. Back out to the acceptance test, if it still fails, back up to Step 3. 1. Commit when you're in a good state, or at a decent break point. 1. Try it out in the browser as a final test, then merge (or rebase and squash) your changes into the mainline. 1. Make sure to at least run tests again before pushing your code up. [![''](http://farm1.static.flickr.com/33/60497202_ca0bd4ae55_m.jpg)](http://www.flickr.com/photos/boojee/60497202/) What's really awesome about this process is the amount of feedback that you get. From testing inputs/outputs of methods in models, giving good and bad data to individual controller actions, and out to integrating the entire stack with [Cucumber steps](http://railscasts.com/episodes/155-beginning-with-cucumber), you get a great sense of how your code works and what it can withstand. Beware though, this feedback loop is addicting! I couldn't really imagine coding in a different way now that I've experienced this. I certainly wouldn't want to take a step backwards and not test anymore, but I am curious as for what's the next evolutionary step. The biggest roadblock I've ran into so far is with mocking and stubbing. The technique as a whole is somewhat new to me, and although I see how much it helps especially with speed and isolation of tests in general, I do fear that [I'm doing it wrong sometimes](http://www.patmaddox.com/blog/you-probably-dont-get-mocks). Hopefully over the next few months I'll get some great experience with [Mocha](http://mocha.rubyforge.org) and maybe even [RR](http://github.com/btakita/rr/tree/master). If you've got a similar coding feedback cycle, or are trying to achieve one, let me know in the comments! I'd also be interested in hearing about other issues you've run into with TDD in general.