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…
    try
    {
    //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 );
    }
    catch
    {
        //do nothing here….
    }
    finally
    {
        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.

If you haven't subsribed yet, you can subsribe below: