12 Lessons I learned from Unit Tests/TDD is a great article for practically adding TDD to your teams rhythm. I can’t stress enough how much point 8 makes a difference: Pair programming helps the team to adopt TDD. When we are trying TDD for the first time or when our deadline is tight, we will have the will to forget the tests and write only production code. Pair programming will prevent the team to cut corners and will keep it writing tests. ...
Last night I did a #pairwithme session with Karl Meisterheim. He’s an experienced developer who currently work part time and was looking to improve his skills. Besides having a good deal in common and really enjoying our conversation, I also learned a bit more about remote pairing and came away with a couple of observations. First off, we paired 2 nights in a row for about an hour each night. Both sessions we tried to solve the same problem: TicTacToe. We started off on the second night with the code from the first night, but quickly threw it away and decided to “start over” as an excercise. Doing this taught me the most significant lessons from our session. ...
I spent a little (longer than I thought… maybe 2 hours?) implementing Tic-Tac-Toe in the TDD As If You Mean It style. Ended up with a VERY different implementation than I ever would have done if I just “started coding” – everything was only in one class, including the AI to “play” against itself. Observations: It was quite different to implement things inside the test method. I ended up coding like it "does something..." do player = Player.new def player.something # do work end player.something.should be_true end It was difficult to not refactor as I went. Many times I would see the duplication and want to refactor immediately. I resisted this urge until I felt the implementation was done, then refactored out duplication, ensuring that the tests continued to pass after each change. I’m still not quite sure how you’re supposed to improve design without breaking the rules. Doing pure method move seems limiting and doesn’t allow for you to see duplication. The only thing I could think of is that there can be additional refactoring after you’re “done” All in all, a very interesting exercise. I want to do it now on something broader, and eventually on something that has a core with a wrapper so that the core is purely TDD’d and the wrapper is thin, but swappable. I think Dominion is my next big attempt.
When pairing, especially remotely with someone you don’t work professionally with, it is sometimes helpful to have some ideas about how to go about getting the session going or what to do. This is just a set of ideas that might get the ball rolling. Problems to work on PuzzleNode - 15 shortish (30 minutes to 4 hour) problems. Great for pairing. Conway’s Game of Life - Can implement a basic version quickly. Lots of ideas for restrictions on this site. TDD Katas - Can be done in 30 minutes alone. Dominion - A larger problem, but it will tease out larger design issues that you don’t get with smaller systems. Build a Twitter - Simple system that can be extended. Adding a UI and continuing strict TDD is very interesting since you might be able to TDD the core system, but have more difficulty with the surrounding. Are there ways to mitigate the risks of using a framework as a shell? Are there ways to make the shell “swappable” – not so you’d actually swap, but so you have loose coupling? Ideas to practice Ping Pong - Pair back and forth, one writes a failing test, one makes it pass, then writes the next failing test, and so on. Various Limitations - No loops, no conditionals, limit lines per method, no voice communication (or typing out in chat… only communication is through code) TDD As If You Mean It - Strict TDD that involves real tests before code and strict refactoring rules. This can be combined with any other limitation or idea, but it’s so difficult (And rewarding) that it’s okay to Just Do This. Tools Vim + tmux - how to tmux · tmux basics screencast · Syme · easy ssh/public key auth Screen Sharing - ScreenHero · Google+ (read only) Audio - Skype · Google+ Find Pairs - RubyPairs · IRC #pairwithme · Twitter #pairwithme
I’ve long put off testing my controllers because of user authentication and nested controllers, dealing with stubs, etc. But today, a fully working test! As background, Advertisers have many trackers and the routes look like this: ActionController::Routing::Routes.draw do |map| map.resources :advertisers do |advertisers| advertisers.resources :trackers end end To set everything up in the specs, I included all the files in the spec/support directory and used Mocha as my mock framework Dir[File.expand_path(File.join(File.dirname(__FILE__),'support','**','*.rb'))].each {|f| require f} Spec::Runner.configure do |config| config.mock_with :mocha end Then I set up my factories (rather than fixtures) using Factory Girl ...