4

I'm writing tests for the following class:

public class Foo : INotifyPropertyChanged
{
  private int _failCount;
  private int _totalCount;
  public double FailRate
  {
     get
     {
        double returnValue = 0.0;
        if (_totalCount > 0)
        {
           returnValue = (double) _failCount / _totalCount * 100;
        }
        return returnValue;
     }
  }

  public int FailCount
  {
     get { return _failCount; }
     set
     {
        if (value != _failCount)
        {
           _failCount = value;
           onNotifyPropertyChanged();
           onNotifyPropertyChanged("FailRate");
        }
     }
  }
  public int TotalCount
  {
     get { return _totalCount; }
     set
     {
        if (value != _totalCount)
        {
           _totalCount = value;
           onNotifyPropertyChanged();
           onNotifyPropertyChanged("FailRate");
        }
     }
  }
  protected virtual void onNotifyPropertyChanged([CallerMemberName]string name = null)
  {
     if (PropertyChanged != null)
     {
        PropertyChanged(this, new PropertyChangedEventArgs(name));
     }
  }

  public event PropertyChangedEventHandler PropertyChanged;
}

I was writing some tests for the FailRate property, and it occurred to me that I should probably make sure that getting FailRate doesn't throw an exception. The case being someone (probably me) removes the if (_totalCount > 0) check, and then getting FailRate throws a DivideBy0Exception.

So I wrote a test that makes sure getting FailRate doesn't throw an exception.

[TestMethod]
public void GettingTheFailRateWhenTheTotalCountIsZeroDoesNotThrowAnException()
{
   Defect defect = new Defect();
   defect.FailCount = 0;
   defect.TotalCount = 0;
   double dummy = defect.FailRate;
}

However, that test doesn't have an explicit check, and will pass as long as the property doesn't throw an exception.

Is just checking that a property doesn't throw an exception a "valid" test?

1
  • It's really up to you to determine whether or not a test is worth doing. If you feel safer doing that test, that's already a good enough reason to run it.
    – Crono
    Feb 19, 2015 at 20:03

2 Answers 2

4

In my opinion, yes. All logic - meaning all conditional code - can be tested. And this is an edge case, too.

By the way, this code is not thread-safe - _totalCount could change between reading its value in if and actually dividing by it. But thread-safety might not be among your requirements.

As for the check being explicit or not, it's a matter of taste. You could catch DivideByZeroException and call Assert.Fail (or whatever it's called) in the catch block. More verbose, but very clear for the reader. As a fellow coder, I'd be okay either way.

And that the routine being tested is so simple? Mixing imperial and metric units crashed a space probe worth $125 million, and this doesn't sound like a very sophisticated bug.

Maybe someone is going to write a similar piece of code for this project - calculating estimated time left, for instance - and having seen this test will prevent a mental lapse by reminding them there are zeroes in this world and zero can't be divided by? It can't hurt...

7

Is just checking that a property doesn't throw an exception a "valid" test?

Yes, it can be. In this example, I would explicitly check that FailRate returns 0 for that input.

And I certainly would validate that the bad input is handled properly by writing the test. I'd probably write a test with a negative value as well to make sure it was > 0 rather than == 0 since it takes like 10 seconds and better encodes the requirements into the test.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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