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.

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?

    [Test]
    public void CarEngineCalculatedValue()
    {
        BusinessObjects.Car car= new BusinessObjects.Car();
        Assert.GreaterOrEqual(car.Engine, 1);
    }

    [Test]
    public void CarNameCalculatedValue()
    {
        BusinessObjects.Car car= new BusinessObjects.Car();
        Assert.IsNotNull(car.Name);
    }

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?

share|improve this question
    
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 '12 at 13:33

2 Answers 2

up vote 12 down vote accepted

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.

share|improve this answer
    
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 '12 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.

share|improve this answer
    
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 '12 at 13:36
1  
@aspdotnetuser and when in doubt, favor more tests; and more granular tests. –  Telastyn Jul 11 '12 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. –  meddlingwithfire Jul 11 '12 at 22:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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