Just awesome stuff, my favorite yet. Make sure you follow Aaron on Google+ as well, lots of cool Ruby and Rails related stuff there.

The way I’ve coded since, well, forever has been like this.  I open up my editor window, and an output window.  When I was writing C code back in the dot com days this was another terminal with a “make && ./app” in it, and in my newer web application days, a browser window with my mouse hand on the reload button. After a bit of code was written, I’d either hit “up-arrow enter” for C code or reload the browser, and see what’s happened.

Watching the screen-cast I realize that Charles was doing the following (as far as I can tell, as I’m pretty new to the whole TDD thing):

• Writing a scenario or feature (using cucumber)
• Using that to generate tests (with rspec, I think)
• Running the test, watching it fail
• Writing the code to make the test pass
• Running the test, watching it pass
• Repeat…

Now the last four steps I do know about, those are standard TDD methodology, broken down into Red (write a failing test), Green (make it pass), Refactor (make the code better), but I was blown away with the realization that he wasn’t looking at the output of the code he was writing, but instead was letting the testing framework do the work, so instead of having to verify with your own eyes that the [insert web page you're interested in here] is showing properly, you have it checked programmatically, no browser needed (in fact, at the point in part two when the browser is needed, there’s that uncomfortable pause while FireFox groans and raises itself into a running state).

Is that what TDD is really about?  I’ve always imagined it as an augmentation to the previously-described way I used to code in that before I coded and reloaded the browser window you’d write the test, then the code, then the browser reload, then the test again to make sure it passed.

This is a whole new world that’s frankly thrown me for a loop, and into a fervor of reading up on cucumber.  I’m not sure how this will affect my code writing, but this makes the whole world of TDD a lot more interesting!  Course, I’ll have to re-watch the two episodes to make sure I truly grok the tools that he’s using.

Further Reading / Links

• Part 1 and Part 2 of the screencast in question
• Teach Me To Code Screencasts (TMTC hold two coveted places on my list of programmer podcasts)
• @teachmetocode and @charlesmaxwood on Twitter
• The #teachmetocode IRC channel on Freenode, come by and hang out and chat

• RSpec syntax takes a bit to get used to
• RSpec philosphies take a bit to get used to…. understanding the :before block, lets, contexts, descriptions, and subjects are all great, but it’s even better to have an idea about the best practices associated with them
• The overall idea of TDD.  Do you want to test the actions that a user is taking?  IE: “Create an object”, “alter an object”.  Or do you test each individual function in the system?  IE: new() create() destroy(), etc.  If the latter, are you expected to test all the functions you don’t create, ie: the built in object methods that you get when you have any class?
• How far do you take TDD if you’re just trying to get a 3 function class off the ground?

Luckily the test-driven @dkubb was there to help me out a bit, and gave me this nice setup to start with.  This let me see the proper (or at least how Dan did it) setup for where a context/let/description/etc block goes.  All good stuff.

Now I have a model (so to speak) I can work from, so now I can finally get off my ass and get some code written.  Dan’s philosphy is that if you code for more than a few minutes at a time you’re doing something wrong, and you should be testing, coding, testing, coding and then doing some more testing before you do more coding.

Last night I finally broke through this a bit.  Amidst my mother-in-law drilling and cutting (she’s helping my wife put up cabinets) and my brother-in-law on the couch oohing and awwing over heavy equipment ads on craigslist, I managed to get things done.  I figure a bit of post-mortem might help me for the next time it happens.

The two things that I had on my plate were not, in fact, the only things needing to be done, but they were the two things that are fairly isolated and sort of simple.

The first was adding ‘areas’ to my referee site.  Each club has many fields, each field has many games.  I wanted to expand this so that each club has many areas, and each area has many fields, and so on.  Basically this allows you to break up the “Langley” club into say, north south east and west, and assign users to various areas and make things a bit more manageable.  IE: Assignor Bob manages the north zone, while Manager Sue takes care of South and East.

Code wise it’s pretty simple, add a new model, add the “has_many” and “belongs_to” relationships, and create the management pages.  Simple stuff, so what’s the problem?

I think it might have come into the testing part again.  Because I’d have to rearrange some of my queries to ensure that users get the right games from the right fields from the (now) right areas from (breath) the right club, having no testing set up means that I’d have to go to all the pages that access that code, redo the queries, re-test, etc.  Ugh.

The second task that was a real stumbling block was the user and role management.  I had set up user authentication a while back, and if you log in as one of two user types you’d end up being sent to the “correct” page, and the two different controllers (/bids and /assignments) are protected through a before_filter as well, but I hadn’t gotten around to “Management” stuff (editing games, fields, etc) yet.

The big mental block that I had in this area was that I had 3 fairly clearly defined roles, 4 if you include the “unauthenticated” users.  I had

• Referee (can bid on games)
• Assignor (approves/edits referee bids)
• Club Admin (club management stuff)

All the stuff in the User model is geared towards these, a club_id is defined and required, email is required, etc.

The role that wasn’t so easily defined was the “master” admin.  This is the main user that would manage the whole site, set up clubs, and basically have access to everything.  I faced the challenge of either creating a new type of authentication and model (ignoring the DRY principle), putting a bunch of exceptions in (ie: requires validation of club_id unless this user has a role type of ‘masteradmin’) and making things ugly.

I managed to push through the first one, or at least start to.  I’ve managed to get to the scaffolding part anyway.  Also in my lunch hours I’ve started going at the failing tests too.  That’s a whole other blog post though, probably involving me going back to the simplest cases that are in the Rails Tutorial book and figuring out how to deal with speccing out password protected pages

I think I saw testing originally as a really nice thing to do in theory, but something that was quickly glossed over when you have your boss looking over your shoulder and wondering just why your project was late, just write the damn thing.

I actually discovered testing in Perl around 2003 with Test::Unit, when I was working at a company that did an online game site for school students.  I read about testing, grabbed Test::Unit and Test::More and proceeded to do add some rudimentary tests to the model to do things like ensure that instantiating a new User model always created an object of the right type, that sort of thing.

I proudly told my boss this.  His response was something like “neat”, with the unspoken subtext of “why aren’t you doing your work and wasting time doing this”.

Fast forward to the TDD happy fun world of rails.

I’m now a couple of weeks into my referee management site.  It’s got a non-trivial, but not hugely complex set of models and interactions and I want to make some (moderately) major changes in some of the architecture.  It terrifies me (well, maybe terrify is too strong a word) to make these changes without being able to just hit a button and know, know, that everything still works properly.

I started creating my models and controllers based on the Rails Tutorial site and using the “rspec_” syntax.  IE:

script/generate rspec_controller Foo

This creates a set of default RSpec tests.  Of course, the defaults are standard stuff, making sure that creating the object returns the right type of object, etc. Luckily a bit later on in the book there is a section on setting up your first tests.

The first challenge I have to create some of my tests (again harkening back to my “rails makes it seem sooo easy, but when you do it it’s a lot harder” rant), is that most of the pages on the site (that do interesting things anyway) are password protected. So now it’s a trek to find out how to deal with speccing out pages that are password protected to help fix the 24 failed tests I have sitting now when I run ‘spec spec’

So let that be a lesson to you all…. do your testing from the start, and set it up from the start like I should have (and knew I should have).