Monday, June 6, 2011

Should You TDD Controllers?

If you use Selenium to test your website should you TDD your controllers?

My default stance is to TDD everything, so why would I even ask this question?  Because controller tests are just a mess of mocks and therefore tend to be time consuming to write, brittle, and mostly just verify that you called things in the right order...  This is especially true if you write thin controllers by pushing logic into "service" classes and your models.

Controller is one of the Object Stereotypes which is defined as "Controls and directs the actions of other objects.  Decides what other objects should do."  So this is an object that just deals with other objects.  That's why it's so mock heavy to unit test.

If you have Selenium (or whatever) tests that drive your website, then you have integration tests on your controllers, and, indeed, your full stack.  So at least the "happy paths" of your controller are covered.  And arguably covered in a more useful way than unit tests.

So, for argument's sake, lets say you agree with me that controller unit tests are mock heavy, expensive to write, and of limited value.  So what value do they provide?  One thing stands out above all others: error handling.  Especially errors from "services" which may depend on infrastructure concerns like file systems and web services or whatever.  Its difficult to test failures in these types of things without mocks and its difficult to mock in a Selenium test.

So, should you TDD controllers?  I think, only when it provides you enough benefit to out weigh the costs (imagine that).  For me, that means I don't test controllers that just do standard CRUD operations and handle 404 errors.  Those are trivial, fully covered by selenium tests, and take too long to mock.  But anything more complicated than that, I test.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.