*[ Update: I've updated the description here to make it clearer. Some of the comments indicate that I did not explain myself as well as I should have. Perhaps this is better.]*

Math Algorithms are problematic. The biggest problem with testing them is that you either end up reproducing the calculation in your test, or you test inputs and outputs blindly. If at all viable, the latter is the more reasonable choice, for several reasons outlined below.

**public int Add(a,b)**

**{**

**return a+b;**

**}**

**[Test]**

**public void Add()**

**{**

**int result = Add(1,2);**

**Assert.AreEqual(1+2, result);**

**}**

**[Test]**

**public void Add()**

**{**

**int result = Add(1,2);**

**Assert.AreEqual(3, result);**

**}**

our result is known and so we can at least "smoke test" the algorithm.

As some of you have mentioned in the comments - there's still the pesky matter of Edge cases and unvalidated input.

There's always room for edge case testing, I agree. In fact, you'd be a fool not to ask yourself what happens when you get two int.MaxValue s. Since this entry does not deal with edge cases, I'd just declare that yes - you would most definitely test edge cases. That's because - edge cases have a particular requirement - they need business logic, or else they woudn't be edge cases. If I wanted the method to just blow up on int.MaxValue, I'd just let it do that, and let the exception bubble up. Since there seems to be a staggering requirement for handling such an edge case - there's obviously some sort of non-math logic in the works here that needs to be written.

Here's a short example:

**[Test]**

**[ExpecteException(typeof(CalcException)),"Sum resulted in an overflow and is illegal")]**

**public void Add()**

**{**

** Add(int.MaxValue,1);**

**}**

Now you're talking. There HAS to be some logic inside the method to make this work - that means it's no longer just a math algorithm - it's a math algorithm hidden underneath a business rule, for which you would exactly do these kinds of tests.

The solution might look like:

**public int Add(int a, int b)**

**{**

**if(a>= in.MaxValue)**

**{**

**throw new CalcException("Sum resulted in an overflow and is illegal");**

**}**

**return a+b;**

**}**

Now you'd have to write a new test to send b as a max value, but you get the idea. It's no longer a math function in purity. You no longer test inputs and outputs - you test logic.

In fact - you could refactor it to show this distiction more clearly:

**public int Add(int a, int b)**

**{**

**if(a>= in.MaxValue)**

**{**

**throw new CalcException("Sum resulted in an overflow and is illegal");**

**}**

**return sumNumbers(a,b);**

**}**

**private int sumNumbers(int a,int b)**

**{**

**return a+b;**

**}**

*For pure math functions:*