http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Following 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. http://ayende.com/2304/unit-testing-trivalities#comment6http://ayende.com/2304/unit-testing-trivalities#comment6Wed, 11 Apr 2007 22:05:11 GMT> THEN I would start testing the refactored classes and then the test for this method is peanuts. 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'd be more inclined to test this in watin as the logic is so trivial and easy to read 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. http://ayende.com/2304/unit-testing-trivalities#comment5http://ayende.com/2304/unit-testing-trivalities#comment5Wed, 11 Apr 2007 17:29:27 GMTAt 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. http://ayende.com/2304/unit-testing-trivalities#comment4http://ayende.com/2304/unit-testing-trivalities#comment4Wed, 11 Apr 2007 11:28:46 GMTFirst 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. http://ayende.com/2304/unit-testing-trivalities#comment3http://ayende.com/2304/unit-testing-trivalities#comment3Wed, 11 Apr 2007 08:56:03 GMTI'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. http://ayende.com/2304/unit-testing-trivalities#comment2http://ayende.com/2304/unit-testing-trivalities#comment2Wed, 11 Apr 2007 08:20:17 GMTFor: * 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: * Hm... takes more typing? 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. :) http://ayende.com/2304/unit-testing-trivalities#comment1http://ayende.com/2304/unit-testing-trivalities#comment1Wed, 11 Apr 2007 07:24:24 GMT