Ensure that your Unit Test is true inspector of bad code

December 29, 2009 UnitTesting No comments

Few days ago I did refactoring and as I’m quite sure that we have good coverage I checked-in my code after all tests passed.
But today QA from my team stated that he/she cannot save new Customer. I dived into log files and found that exception occured on SaveCustomer method.
Ok, I moved to the appropriate UT. (Note: it passes ok.) Which looked like:

[Test, Category(“Integration”)]
public void SaveCustomer_EnsureWeCanCreateNewCustomer()
    Customer customer = new Customer();
    //some another setup code here…
    //we hit database to save newly created customer
        savedCustomer = CustomerRepository.SaveCustomer(customer);

    //now we fetch customer from database requesting with the ID of just saved customer
        fetchedCustomer = CustomerRepository.FetchCustomer(savedCustomer.ID);

    //if fetched customer is not null we are ok!
        Assert.That( fetchedCustomer, Is.Not.Null );
        //do nothing here….
        if ( fetchedCustomer != null )
        //we want to leave our database clear after test run
            CustomerRepository.Delete( fetchedCustomer );

This Unit Test will be succeded anyway, because
Assert.That(fetchedCustomer, Is.Not.Null) and similar asserts generates AssertionException.
Honestly I’m not aware why there was that catch{} piece, but anyway you could put there two catch blocks if it is really needed – one specific for the AssertionException and another for all cases of our life.
When you write your Unit Test you need to see it in both states – first
in failure and then in success. After that you can allow yourself
commit that code.

Main idea is:

You always need to keep one’s eye on quality of you Unit Tests and be sure that your Unit Test will fail when that is needed.

No comments


December 21, 2009 UnitTesting No comments

Have you ever faced with UT that failed once and then you always see it succeeded?

One of such tests could be test where you verify that date properties of some newly created entity are equal if they take DateTime.Now for that.

Today Hudson showed me that some test failed in project I worked near half a year ago, so test looked like:

var item1 = new Item();
var item2 = new Item();
Assert.AreEqual(item1.CreatedDate, item2.CreatedDate);

Test failed because time difference between dates was greater than few milliseconds. This could occur when processor is too occupied.

So I changed assert call to more realistic:

public void AssertDatesAreEqual(DateTime dateTimeLeft, DateTime dateTimeRight)
     Assert.IsTrue(Math.Abs((dateTimeLeft dateTimeRight).Milliseconds) < 100,
    “TimeSpan difference between dates is greater than 100 milliseconds.”);

No comments