I have created a small C# project to help me learn how to write good unit tests. I know that one important rule of unit testing is to test the smallest 'unit' of code possible so that if it fails you know exactly what part of the code needs to fixed. I need help with the following before I continue to implement more unit tests for the project:

If I have a Car class, for example, that creates a new Car object which has various attributes that are calculated when its' constructor method is called, would the two following tests be considered as overkill? Should there be one test that tests all calculated attributes of the Car object instead?

    public void CarEngineCalculatedValue()
        BusinessObjects.Car car= new BusinessObjects.Car();
        Assert.GreaterOrEqual(car.Engine, 1);

    public void CarNameCalculatedValue()
        BusinessObjects.Car car= new BusinessObjects.Car();

Should I have the above two test methods to test these things or should I have one test method that asserts the Car object has first been created and then test these things in the same test method?

  • The example I included in my question is testing values that are dynamically calculated for each car object, so they could be between a certain range (if a number value). Would you have the tests testing each attribute like in the example or a longer test method that tests them?
    – Theomax
    Jul 11, 2012 at 13:33

2 Answers 2


To me, a unit test case (method) should test a single test scenario. This may require multiple asserts, and IMO this is fine. As both of your test methods are exercising the same scenario (creating an object and ensuring it is in a consistent initial state), I would merge them into a single test case.

As to how to discern what exactly failed out of multiple asserts, all the assert methods I can think of have overloads with an extra message parameter - use this wisely to provide clear failure messages.

  • Agreed, I would far prefer a few well-targeted scenarios with (at least) 3 to 5 asserts. Unfortunately the OP's example seems to have randomly generated values (no inputs to the Car object), making that kind of difficult.
    – Daniel B
    Jul 11, 2012 at 14:11

I would prefer the two method approach. When one dies, you know specifically why it died and can fix it quicker. You don't have to test as much if requirements change part of the attributes.

That said, it's not the worst thing in the world to bundle some trivial checks like these into a 'does the car get built properly?' test.

Tests exist for your benefit, so do what benefits you the most. If the tiny tests are so annoying that they don't get written, that's way worse than the minor issue of bundling them.

  • So basically, it's if I decide how closely I may want to test each attribute for the car object? And if I decide making those tests will allow me to have more confidence in the code then it's worth making them (aside from the other advantages of knowing exactly what attribute calculation isn't working if the test fails)
    – Theomax
    Jul 11, 2012 at 13:36
  • 1
    @aspdotnetuser and when in doubt, favor more tests; and more granular tests.
    – Telastyn
    Jul 11, 2012 at 13:38
  • +1 for the "Tests exist for your benefit". Many people get lost as zealots to "proper" process. Really though, just think critically about your tests; If they are a solution to your problem, then they're good. Jul 11, 2012 at 22:21

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.