In which I discover that yes Virginia, there is a good reason to write tests from the start.

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

I’ve always heard that reading others Ruby source code is a great way to learn the language, but until recently this, like many other things that are “commonly known”, was something outside my realm of grokking. However today I was looking to convert user input URLs into something reasonable, ie: “foo.com” should be saved as “http://foo.com”, and “http://foo.com” should be stored as, well, “http://foo.com”.

So my mentor, or more accurately, the guy I bug with annoying noobie Ruby questions, @dkubb, pointed me to the Addressable.URI library.

I started out with his suggestion of:

params[:url] = Addressable::URI.heuristic_parse(params[:url]).normalize

But found it didn’t work quite as I wanted. After a bit of searching some blog posts I found that the function I wanted was the heuristic_parse, which will try to intelligentally create a valid URI.

Since I’d been “in” Ruby for a few weeks now, I figured why not, and hit the ‘view source’ button on the API page. This was the grokking moment. The “thinking in rails” as it were.

The problem I’d had before wasn’t that I didn’t read Ruby all that well, but that I didn’t have a direction to do it. Randomly opening up functions, or the Rails core code, or someone’s library didn’t make nearly as much sense unless you had a reason for it.

You know how they say the best way to learn something is to need to use it (well, someone say something like that anyway)? Well, this was it. I knew what I needed to do (turn “foo.com” into “http://foo.com”, I had played around with it in IRB so I knew it worked, and now I was a mouse click away from being able to read how someone did it.

The heuristic_parse function is only about 30 lines long, and if you can remotely read regexes, it’s competely readable.  Now I have a place to start reading, seeing how other people write code and start learning some of the common idioms that I might be missing.

Short story long, reading others source code is a great thing to do, as long as you have a place and a reason to start, otherwise you may just confuse yourself more.

So over the last week I’ve dug into my referee site project quite a few times, mostly in small chunks over the weekend.  I’ve noticed that I have slightly less fear now, but also that now I’m starting to reach my limit of knowledge of Ruby and Rails, and find myself starting to fall back to my old hack-and-slash perl practices.

This isn’t all bad though.  To quote the great @curtismchale:

“getting code out is better than sitting on it forever to make it ‘perfect’”

The idea that has permiated rails from the time I started reading about it in 2004 till now is “iterate”.  So is it bad that I have multiple authentication methods in multiple controllers, all of which do the same thing, when I can just go back and fix it later?

I would say, “kinda”.  The old axiom of “make it work, then make it fast” applies here, but within reason.  You don’t want to over-design, but you also don’t want to under-design.  I think the key to the iterative process is two-fold:

1. Iterating only works if you do it fairly quickly, not say to yourself that you’ll go back and fix it and don’t get to it until the project is over.  From what I’ve seen personally it works best if I:
   • Finish a task
   • Go back and make it work better^{(see point 2)}
   • Or:
   • Work on something else that’s related or could affect the previous tasks design
   • …. then go back and make the first task better^{(see point 2)}
2. You almost need, neeeeeeed a test driven design or at minimum, some tests.  Without tests, it can be very hard to tell if you’re breaking anything when you iterate.  So in a perfect world you would:
   • Write your tests
   • Code until the tests all pass
   • Go back and make it work better
   • Ensure your tests all pass

If you write code and do nothing but refactor and refactor and refactor, but never release it, is it any different than not writing the code at all?  Do you need to make it perfect before you release it to the world (note: this answer varies if you’re writing a blog entry, a web app to count your shoelace collection, or the space shuttle launch sequence)?  Does it have to be 100% optimized before you release it to the world?  Thinking of the last one, I’d say there’s a huge case for writing tests here!

Sometimes though, I think it’s OK to just move on the the next part of the project.  Depending on the goals (ie: is it “real” work, a personal project, a web-app just for learning, etc) it might be better use of your time to move onto the next big part of the project and know that you’ll come back later to make sure that your code is like a rainbow puking unicorn like it should be

Over the Goatee Plateau

… well, the start of grokking it anyway.  Maybe it’s because I’ve finally made it over The Goatee Plateau, or maybe it just sort of clicked and all the bits and pieces that I’ve been reading about since 2004 started coming into play.

More likely though, is I finally got around to stopping worrying about coding and started coding.

I could tell you that going through the excellent Rails Tutorial site by the most awesome Michael Hartl, gave me some confidence or addressed things differently than the thousands of other free Ruby on Rails sites out there.

So here’s the story.  About 3 months ago a web designer I’d worked with before brought me a project.  The project was a relatively simple, but still complex enough to be interesting, site to allow scheduling of referee’s for the local sports division.  Basically there was the need for users to schedule the games, referees to bid on the games they want to ref, and then “assignors” to select the refs to games.  There’s more to it, but that’s enough for here (I’m sure I’m boring you already).

The point of that is that it’s a small project without the need for any really crazy stuff, but not a super simple “we need a weblog in 15 minutes” type requests.  Additionally, there was enough complexity in the project that doing it in my primary language and framework, Perl and HTML::Mason was something that I’d consider actual “work”, and I got the same cold shiver I get when contract clients come to me with “just one quick little change…”.

So I told her that I’d do it, and work on it.  There wasn’t a deadline, or any agreement on money, and I took this as a learning “fun” project with the only thing that I was planning to really get out of it was knowledge.  A couple of days later I set up a Heroku account, and uploaded an initial set of files (the result of a “rails <sitename>” essentially) without any changes or additions.

And it sat there for 2 months.

I was terrified of doing something with it.  As I’ve written before the Ruby on Rails world has changed since 2004.  It used to be a relatively small ecosystem around 2004 when all your code was auto-generated and all you needed to know was the syntax of an “each” loop in Ruby.  Now it’s a huge and complex world of Cucumber tests that write their own tests, NoSQL and Mongo databases, Markdown and Textile, and about a thousand other gems, plugins and libraries that may or may not help you out with whatever it is you’re doing.

Terrified by the choices available maybe?

A couple of weeks later I actually started out doing a bit of work while at a Fraser Valley Ruby Brigade meeting.  Nothing special, just creating some of the models required and trying to get them properly related to each other.  However, after creating the scaffolding I still had that feeling that I really didn’t know what I was up to, I froze up again.  My brain kept on jumping forward into all the “hows”.

“How will I put all this under the old familiar “/admin” setup when all the routes are /referees/ and /fields/ and /games/?”

“If I set up all the smaller models (ie: a list of pay scales) do I need to set up scaffolding for those too? Where do they go?”

“How will I set up the user authentication?  What will I use?  How do I set up my models ahead of time to make sure I don’t shoot myself in the foot for this?”

And it sat there for another month.

Then last week I made a breakthrough of sorts.  I’m not sure if it was going through the Rails Tutorial, or the awesome DataMapper ninja @dkubb giving me the great advice of (paraphrased)

“Just do it in as simple a way as possible, whatever design you come up with will be wrong, so make sure you do the minimum of work to get it working so there’s that less code to change when you come up with a better design.”

Something in there got through and I just started… “getting” it.  I started with the highest level of object I could think of (in this case, the fields that the games would be played on) and created that, then created a main page that would show them.  Then the next level of object (games) and connected them.  Then the next and the next.  So far I’ve really not done a huge amount more than hand writing the scaffolding that rails does for you anyway, but using some of the techniques in the Rails Tutorial I have slowly been iterating my way forward.

One big hole in this project has been testing.  Even though the Rails Tutorial starts almost right away with doing RSpec tests I haven’t put those in.  I also have avoided doing any “real” work on the site, doing other than the scaffolding type stuff.  But still, not having to worry about needing the generators to create views, and knowing what I need to add to a controller to have something start working has been an amazing weight off my shoulders.