views:

176

answers:

2

How granular should one get when using TDD/BDD methods for developing an application? In particular with regards to a Rails application.

Would you test for every single field individually and then right the migration that will make it pass? So every field would have it's own migration? What would you actually test against to make sure the field was their?

I'm really trying to get my head wrapped around where to start and how granular to get. I go to get started and just freeze because I don't know how to test every little thing.

Most of the examples I've seen use validation as an example. I know there is a lot more code written before that and I just don't know how to test the most basic of things like "should have a first name field".

Any help is much appreciated.

THANKS!

+1  A: 

Are you using any tools for TDD/BDD such as Cucumber?

They have some good info about using Cucumber with Rails.

Basically write your feature and then a scaffold to make that feature pass it's tests. When you want to add another field to your model, first update the feature, let it fail, then write a migration and update your view to make the tests pass.

Trevor
So we're talking zero code generation here right? I mean, if you create a scaffold w/ 3 fields, you've now written code w/ no tests first right?
Phil
The tests are written first. They will fail because there isn't any code written yet to allow them to pass. Then, generate your scaffold which will allow the tests to pass. Once the tests have passed, repeat.
Trevor
I thought with TDD, you write one test for one minute thing, then you write just enough code to make it pass. Writing tests for a bunch of code and then using a generator to make them pass seems to defy this.
Phil
You're right Phil
Alex Baranosky
+1  A: 

I wouldn't drill that far down. In fact, I don't usually test my migrations, and it's certainly not worth your time (in general) to test getters and setters. Stick to tests that teach you about the system, and express non-trivial functional requirements of the code.

As far as where to start: Pick a requirement that you know how to test - one without outside dependencies, one where the path is absolutely clear. Write the test(s) to describe the desired behavior, implement it, and refactor the code to remove any ugliness you may have added during the implementation. After you've done this for a few features on the list, you'll probably find that some of the fuzzier features are coming into focus because you've made the building blocks/dependencies that they need.

A good book that goes into more detail on testing practices than AWDR or The Rails Way is The RSpec Book, a beta of which is available in electronic form.

bradheintz