Unit Testing Trivalities?
The following code is a MonoRail action. It doesn't do much, but relies on the framework to do most of its work.
public void ShowCustomerDetails([ARFetch("id")] Customer customer)
{
if(customer==null)
RenderSharedView("common/notfound");
PropertyBag["customer"] = customer;
}
What are the arguments for/against testing this method directly?
Comments
For:
Tests document intent
There is logic in this method--it can and should be tested.
The test is pretty straight forward and for this particular method doesn't even require any crazy mocking
Only requires two, quick to write tests.
Against:
Caveats:
The whole ARFetch attribute imo is moot, you shouldn't test that here.
Luckily you're not doing anything here that would require any nutty mocking/stubbing in the controller, but even if you were, you should still test it... just hate doing it more. :)
I've been having similar discussions at work lately as we build more abstractions into our application. I'd be more inclined to test this in watin as the logic is so trivial and easy to read, i'd be more concerned with checking that "common/notfound" was present and the view was using the customer property correctly which the unit tests probably wouldn't tell you.
First of all.. lets start with reviewing the code. The code contains string literals that should be replaced with at least constants to minimize typos. I like type safety so I would probably refactor the code so that the property bag is typesafe as well as the view stuff.
THEN I would start testing the refactored classes and then the test for this method is peanuts.
At some point in the last project I was working for, I had started to write some private methods on the controller layer, and I was obviously testing them. The project lead didn't like that, so we decided to create a separate layer for all the logic (we called that AppLogic layer), and we shrink down all the controller layer to be just a dispatcher with no logic at all. Anyway, there are still procedural statements, which are there to exercise similar type of logic of the one presented on your example.
I think you got the order backwards here :) Wouldn't it be better to write tests first (especially if you know its working) and then refactor?
That said, I obviously agree with you on your string literal points:
http://blog.eleutian.com/PermaLink,guid,ba5b573d-9863-456f-8e0d-be8871883eca.aspx
http://blog.eleutian.com/PermaLink,guid,088e158b-cd3c-4920-8df5-a3628013cc1d.aspx
but I'm pretty sure the example was chosen for its simplicity...
I agree that the watin test is more valuable, but that is an integration test... not a unit test, and I think there should be both.
Following Aaron's comment:
If you are TDD/BDD then the method is merely a response to the test in first place. You won't go back and remove the test if the solution turns out to be simple.