Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share|improve this question

marked as duplicate by whatsisname, Jimmy Hoffa, Kilian Foth, gnat, Robert Harvey Jul 23 '13 at 0:25

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

    
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 –  Jimmy Hoffa Jul 22 '13 at 19:44
1  
Is it worth it to you? –  Robert Harvey Jul 22 '13 at 19:47
    
@RobertHarvey my initial response is yes it is, however my team members say no... hence the qusetion, Is it to you –  NimChimpsky Jul 22 '13 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. –  Robert Harvey Jul 22 '13 at 20:19
add comment

1 Answer

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.

share|improve this answer
add comment

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