Using test-driven development (TDD) with Rails scaffolding

0
votes

I'm hoping to better understand the process of using TDD with a Rails 4 application.

The best post I've found on the subject to date is 15 TDD steps to create a Rails application. It suggests following these steps:

  • scaffold a model
  • create unit test for the model --> test fails
  • create migration for model --> test passes
  • scaffold a controller with desired actions
  • create functional test for the controller --> test fails
  • add code to controller action --> test passes
  • create functional test for the view --> test fails
  • create view --> test passes

This approach leads to a lot more work that just rails g scaffold Foo. But using the scaffolder would result in tests (if built) that would pass, violating a core TDD principle.

I've also read that one shouldn't test functionality that is provided by the framework (e.g. unit tests for validates_presence_of).

Which leads me to ask: should I skip unit and function tests for code that is generated by the scaffolder and just test my customizations or should follow the layer-at-a-time pattern used by the blog posting's author?

1
ruby-on-railsruby-on-rails-4tdd
What do you want to use scaffolds for? They only generate the most basic code to do CRUD operations and the generated tests are far from worth using. (Reading the link you have provided: It's from 2007, uses a version of Rails even older than Rails 2, and says nothing about using scaffolding?) – yerforkferchips
@yerforkferchips: Yes, I realize that scaffolding is fairly basic and that its tests are not useful. But with Rails 4, it is a decent starting point that saves time and eliminates omissions. Yes, the article is a big old, but still describes a process. I cited the article as a contrast to scaffolding and a possible workflow. – craig

1 Answers

0
votes

A very nicely worded answer, if I understand your question correctly, is provided in this post:

http://robots.thoughtbot.com/unpopular-developer-5-stop-unit-testing-your-scaffold

In essence, its message is that you should only test what deviates from the scaffold-generated behaviour, as the scaffold-generated tests are too simple to be useful.