3

When practicing TDD, how do you test a domain model? If you don't test, how do you account for code coverage? We want to have 100% coverage (or as much as possible), but despite hours of training videos we cannot find the best solution.

UPDATE: Given a domain model I want to write of User which has properties: Id (primary key), FirstName, LastName, tenantId(foreign key). Do you prefer to just create this model without test coverage? If so, then you start your project with 0% code coverage, right? Then you are getting off to a rough start. But in pure TDD, you should not write code without a test. So what would you do?

Let's take this a step further. What if you have behavior--but just a little? Now your User has Id (primary key), FirstName, LastName, tenantId (foreign key) and birthDate. Then you have a method/function to calculate age based on birthdate. I feel that I should write tests before the age calculation, but not before the model. How would you account for this paradox?

5
  • 3
    This is question as stated is too broad. What have you tried so far? Why does it not seem best? What would make a solution best?
    – Mike Nakis
    Commented Sep 28, 2015 at 19:28
  • 1
    Why would a Unit Test work with a domain model differently from any other code?
    – JeffO
    Commented Sep 28, 2015 at 19:37
  • 3
    The Way of Testivius: "An imperfect test today is better than a perfect test someday." "An ugly test is better than no test." "Sometimes, the test justifies the means."
    – Ixrec
    Commented Sep 28, 2015 at 19:44
  • Please forgive my ignorance, but I typed two more paragraphs of details. Is it possible to get this hold removed?-Thanks!
    – bjscharf
    Commented Sep 30, 2015 at 18:45
  • Normally we start with acceptance tests first and then implement service objects, what comes next is domain models so, ideally you are not starting with 0%.
    – CodeYogi
    Commented Oct 31, 2015 at 15:30

1 Answer 1

Reset to default
4

This is why code coverage is a terrible metric.

If you have a simple DTO (a class with only properties that contains data), there is very little value in testing the methods that get and set those properties. You can, and your code coverage will surely go up, but it's a useless test. You're testing the language and not the code. If you strive for a good coverage, strive for coverage of code that actually does something.

The 'only write code to make a failing test pass' is a very good rule, but it is not meant to be invoked at every turn. In fact, even constructors are evil so we probably should never use them, right? Well, not really. But it is a lot easier (and catchier) to say 'never' instead of 'mostly never, unless...'. The rule that you should never write code unless it is written to make a failing test pass is the same.

With time and application of TDD to your development comes an amount of experience with it that allows you to see where the rule should be enforced and where it should not be enforced.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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