I have been reading the following Uncle Bob post on TDD. He explains that there are cases where TDD is not needed. Mainly in a case where your tests and code are both very specific, and your code is not tending to more general algorithms.

He suggests that logic should be TDDed, and everything that isn't logic should be added to a humble layer. For example CSS. Testing that a css class is 5px would require both the test and code to have 5px hardcoded into both. While tests get more specific, the css will not get more generic, in fact it too will get more specific.

Remember the TDD rule: As the tests get more specific, the code gets more generic. Every new test case makes the test suite more constrained and more specific. To make the new test case pass, the programmer strives to make the production code more general, not more specific....

...Indeed, you could write a program that reads the CSS and writes the tests. Such tests add very little value, and they certainly aren't written first.

This makes sense, but I have come across a case where the same logic could apply, but not sure if I've taken the example in the post too far.

I have a controller class which I have applied TDD to. The classes method returns a view name as a response. Methods may pass different variables into the view, but the view name always remains the same.

The view name will be hardcoded into the controller, and into the test. Is it therefore a pointless test (as per the CSS example) ? As the tests get more specific for my controller, there will never be a case where I can somehow end up making the code that outputs the view name more generic: it will always be hardcoded to return a specific view name.

If it is a pointless test, where should I place this 'humble' code? If the controller is seen as a class that has logic (and therefore needs TDD) and the output of a specific view name is 'humble', how do I account for this in my controller?

Note: When i say the controller has 'logic' I mean that it has TDD testable logic e.g. a controller will pass user data to a model, the controller therefore needs tests that ensure it is passing the correct data to a model.

  • Is "return a view name that never changes" the only behavior of the method? – Robert Harvey Feb 26 '16 at 17:55
  • it also passes some variables out with the view name based on model response - these will need to be tested. But I'm thinking i could pass these view variables to a dumb ViewModel that is then attached to the view name by some dumb class that needs no TDD? – Gaz_Edge Feb 26 '16 at 17:58
  • 2
    If I understand you correctly, Uncle Bob has two things to say about that. He says "export as much of the logic as you can away from the UI [and other untestable layers] to its own module so that it can be tested," and "It's not fair to load [the UI and other untestable] layers with logic just so you can avoid writing tests for that logic." I agree fully with both points. – Robert Harvey Feb 26 '16 at 18:02
  • So I should use a different class to fetch the view name? I can mock that class in my controller test and then test that it is called and returned as the response? I guess thats a nice piece of code that can be tested once for all controllers and added to an abstract controller maybe? – Gaz_Edge Feb 26 '16 at 18:16
  • I don't consider the view name to be a significant factor in this discussion. If the view name never changes, then it doesn't need to be tested. It's like that CSS property that Bob talks about that is duplicated in the CSS and the test. Because there is no generalization present, there's no point in writing a test for it. – Robert Harvey Feb 26 '16 at 18:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.