What's the use of writing tests matching configuration-like code line by line?

I have been wondering about the usefulness of writing tests that match code one-by-one.

Just an example: in Rails, you can define 7 restful routes in one line in routes.rb using:

resources :products

BDD/TDD prescribes you test first and then write code. In order to test the full effect of this line, devs come up with macros e.g. for shoulda: http://kconrails.com/2010/01/27/route-testing-with-shoulda-in-ruby-on-rails/

class RoutingTest < ActionController::TestCase
  # simple
  should_map_resources :products
end

I'm not trying to pick on the guy that wrote the macros, this is just an example of a pattern that I see all over Rails.

I'm just wondering what t开发者_JAVA技巧he use of it is... in the end you're just duplicating code and the only thing you test is that Rails works. You could as well write a tool that transforms your test macros into actual code...

When I ask around, people answer me that:

"the tests should document your code, so yes it makes sense to write them, even if it's just one line corresponding to one line"

What are your thoughts?

To me it's a good pratice to avoid some big mistake.

By example after a merge or an editing this resource is delete. How to know that ?

With this test you can see immediatly, that there are this resources needed. If you want change it or delete it you need made 2 changes. Not only one can be do by mistake.

As my boss(who is also a coder by the way) says, these are fine examples on testing but sometimes you just have to know what to test. In your case, testing that rails works is good, but as we all know, it IS already tested. We don't need to write tests for that.

In our dev cycle, we use tests only for those things that aren't simple/complex/already tested. Say you have a paperclip attachment to a model. We don't test if it's attached already, there's a test for that already made by the paperclip people. What you test is if your model can access that attachment or the process in which you attach it or something.

Something like that :) Hope that makes sense

Rails already has tests for its routing DSL. The only benefit of the macro is that it tests whether or not you have actually included the declaration in your route file which should be implicitly tested through integration test suite.

Remember, adding tests adds more code to maintain. Every time you have some code to write you should ask yourself whether it is worth the time that will be involved in maintaining/writing tests or not. When you are learning test-first, however, it is probably better to be strict as it takes time to learn what is worth testing and what isn't.

Hope that helps.

It's worth looking under the hood to see what the shoulda macro actually does. It checks each route generated by resources :products, i.e. it doesn't simply verify that the resources statement exists in the routes file. So this is not really an instance of testing Rails code that has already been tested.

I don't think that you should test something like that explicitly.

When a page is rendered in test, form_for will complain that a route does not exist. And then I add it. And if it is the resources way or a named route, that does not matter in my view. Afterwards when there are multiple named routes, you can refactor the routes file so you use resources instead of multiple named routes.

There's more to testing than just helping you write better code. You need to make sure that code continues to work in the future... Regression Testing. That's what these kind of tests provide.