Ensure that your Unit Test is true inspector of bad code

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.