Rails TDD - what to write first

Question

I just get into TDD with Rails. What puzzles me is when to write tests. All manuals suggest that you should write tests before writing any code, but if I create a Person model and then write the next test before writing any code,

p = Person.new p.firstname = "mikey" p.lastname = "hogarth" assert_equal p.fullname, "mikey hogarth" 

then the test itself will not fail, it will work! Since I have not yet implemented the "fullname" method, I will get a runtime error. Therefore, I cannot make this test unsuccessful until I write the code.

How do TDD encoders usually approach this situation? Is it mostly with dummy stubs or is there a better way?

=== EDIT ===

Many great ideas have been suggested. In the end, I decided that the next option achieves what I am trying to do most elegantly;

 if p.respond_to? "fullname" assert_equal "Mikey Hogarth", p.fullname else flunk "fullname not implemented" end 

=== SECOND EDIT ===

If you stumble upon this answer, it seems that my approach to TDD was a problem, so while the code above will work, this is not a good practice.

Answer 1

You want to write the code that you had. In C / style languages, statically compiled languages ​​did not even compile the above, since you correctly pointed out that the code does not exist. This is normal, then you should implement a minimum minimum in order to build code in order to run your tests. In other words, your tests drive your design.

My Ruby is very rusty, but in the above example, something along the lines of method_missing will be selected for methods / properties that do not exist. Therefore, you would create them.

 class Person attr_accessor :firstname, :lastname def fullname end end 

If you run your test, you will get zero returned from the full name. Therefore, we will use the fullname method. It should be noted here that the message changed, and does not run, when he groaned about the missing methods, the test groaned, that we did not implement the methods correctly.

 def fullname return @firstname + " " + @lastname end 

Now your test will pass.

Basically, you want to either change the message that your test shows after running (it turns out that you are getting somewhere), or you want to skip it. After passing the test, you can reorganize. The above method is simple, but you can opt out of the return statement, use string formatting, or whatever. As long as the test passes, you know that you are good to go.

Answer 2

It is normal for the test code to crash in these situations. View it as a failure.

Writing the test code before the actual code will give you the opportunity to develop the interface of the tested class before you really start implementing this class. You will have an example of using the class, and that's great!

After that, you will need to create the actual class under the test, and the test will fail, not fail. Then do this test, refactoring and continue recording the failed tests.

Answer 3

My approach would be to use conditional check p.fullname.nil? for this test, or just put assert_not_nil(p.fullname) as the previous test, which if failed will prevent the remaining tests from running.