The advantage is it protects your DTO against future "enhancements" ?

  • There's a good question in there, but you just need to add some detail and info to get to it... give some examples and explain your perspective and what you expect to hear to prove or disprove it Jul 22, 2013 at 19:44
  • 1
    Is it worth it to you? Jul 22, 2013 at 19:47
  • @RobertHarvey my initial response is yes it is, however my team members say no... hence the qusetion, Is it to you Jul 22, 2013 at 20:17
  • 1
    I don't test getters/setters that have no logic in them. If they later obtain some validation or other logic, I add tests at that time. Jul 22, 2013 at 20:19

1 Answer 1


Let me say, first of all, that coverage for coverage's sake is bad. Writing a unit test for your class's constructor, just to make sure that NCover or dotCover sees that the runner went through the constructor code, is worse than useless. If the test makes no assertions, then your build-bot's coverage metrics give a false sense of security. If it does make assertions, then the test will have to change if the assertions ever do, even if no other line of code will care.

Therefore, the answer to your title question is predicated on another question: Do the tests make assertions that other elements of your codebase, or your end users, will care about?

The question isn't about how basic the system under test is; a test that Add(1,2) == 3 can be useful, if that's what the code needs to do and you need to ensure it always does this. It's also useful if you're TDDing (which IMO you should be), because when you make this assertion, the code that will make it true doesn't exist yet. In TDD, no matter how simple an action may be, as long as you need a line of "end-developer code" (not built into the language or a third-party library) to perform an action, you need an assertion that proves you wrote that line of code correctly.

Not the answer you're looking for? Browse other questions tagged or ask your own question.