has_many :thoughts: Tag TDD

Skinny Controller, Fat Model

Colin A. Bartlett — Fri, 01 Jun 2007 21:07:00 -0400

One of my favorite talks from RailsConf was by the team behind The Rails Way. Now back from the road trip and settled in, they have updated their site with some more details about one of the ideas they pushed: Controllers should be simple, basic, and generally have a lot less code then most of us use now. Most of your logic should end up in the model.

There’s many reasons for this but the three I like the most:

It forces you to write code that more easily reused. Limits your temptation to copy/paste from one controller action to another.
Your templates can become more details. @order.total instead of @total (which would have to be mapped to something logic in the controller.)
The code is more easily tested. You can programmatically access the results of the methods in your model without having to munge HTML output from a controller.

Their post has all the details and code samples.

Adding tests to legacy rails apps

Colin A. Bartlett — Fri, 18 May 2007 18:04:00 -0400

This talk was excellent and provided some insight as to how we can start writing tests on the apps we haven’t done jack with when it comes to testing. Since this is one of my main goals for our team in the coming months, I found this talk quite informative. Some tidbits:

Having no tests at all doesn’t mean you can’t start writing them.
- It’s really not that hard to get started writing tests. Rail scaffold will actually generate tests out of the box although the speaker implied they are not very good and might actually even break.
Write a test every time you refactor
- If you are following the principal of putting that extra 10% of effort in to refactoring or improving some other portion of code at every single check-in, you have ample opportunity for writing beginning tests.
- Simply create a test that passes under the current code, then refactor the test, and ensure the test still passes.
We should use RSpec to write tests
- Since we’re just getting started with TDD and writing tests at all, we should start with a tool that of people seem to think is superior to Test::Unit.
- RSpec allows people to write tests in a domain specific language that makes the tests read better and make more sense.
There are some really handy tools available to help us test and help us test our tests.
1. rake stats
  - The rake stats output will show you a ratio of lines of code to lines of tests. You want to have a higher ratio because that means you’re writing a lot of tests.
2. rcov
  - Rcov is a neat tool that will run your tests and show you lines of code that were not tested.
  - With an output similar to the cvsspam diff output that highlights lines of code that the whole body of your tests didn’t run.
3. Heckle
  - Heckle is tool that sounds pretty damn cool. Basically, it fucks up your code and then tells you if your tests failed like should have.
  - Essentially, it changes variables, swaps if statements, and generally wreaks havoc on your code, one item at a time, running your tests each time.
  - At the end, it tells you what tests still passed after stuff was changed and shows you what it changed. By examining this, you can determine what stuff might be tested properly.

I’m pretty anxious to start testing and I think I’ll try out some of these techniques on Find Mini Golf tonight.

Clean Code

Colin A. Bartlett — Fri, 18 May 2007 15:13:00 -0400

I just saw a talk by Robert Martin called “Clean Code” that was pretty eye opening. He walked through the process of coding a small app that parsed command line parameters. He demonstrated a rather common process of creating a small application with a specific function that, when requirements change, can quickly and easily morph into a mess of unmanageable code.

This is a problem we encounter often and was one of my main complaints the ASP applications that we were churning out. We can’t do anything about clients changing requirements, but we can do something about how we keep up with them.

A few points to take a away:

Writing clean code is more important than you think.
- It often seems like a better choice to just get the app done, and worry about the details later. But later almost always requires more work.
Test-first development is the way to go.
- The speaker is an agile development consultant and so he advocated test-first development, of course.
- It was pretty clear to me that refactoring becomes a lot easier, because you can do it with confidence, when you have tests that can ensure that your code still works.
Improve code every time you check in.
- When you add some functionality to an app, make it a habit of always improving something else at the same time.
- A small investment of say, 10% additional work, every time you commit code, of improvement and refactoring of other code will go a long way to improving the app overall. Again, you can do this more confidently when you have tests.
Reading other people’s code is a great way to learn.
- It was pretty interesting to read someone else’s code and learn how they would approach a problem. This is why things like Ruby Quiz are so helpful.

Airlines suck

Colin A. Bartlett — Thu, 17 May 2007 01:45:00 -0400

It’s difficult to blog about RailsConf when one is stuck in a city hundreds of miles away…

Hopefully I’ll get there for at least the second tutorial session tomorrow. It’s a shame, because I was really looking forward to the tutorial about test driven development.

Guess I will just have to spend my hours sitting at O’Hare by reading about TDD.