> That means you're assuming the expected outputs
> are pre-known and can be calculated beforehand
> (using some external tool perhaps such as Mat Lab).
> If they are pre-known, what exactly are you testing?
I'm not sure I clearly understand the problem. The output of any calculation is pre-known beforehand given that the input is known as well. Providing a fixed input, in this case one and two makes the result known as long as the equation doesn't fluctuate or depend on any other set of unknown variables.
In my opinion such methods should be tested against a known *expected* result instead of another calculation. This is how I think most if not all test are - ie you test against an expected static result and not a result of another operation.
Assert.AreEqual(3, result);
Alex
is it a riddle? i guezsz...Al-Chowarizmi..
However, many business calculations have an "official" formula, but if you get a range of inputs and expected outputs they differ from the formula for various reasons. However you do have to have the "default" test for completeness sake.
And the default test you show there, what happens when I test that with 2 integers that are max size? What should the method return then? That's still necessary to test.
And I would second Alex's opinion. Don't redo the calc in the assertion, that's why the Intel floating point bug was never found. :)
I think you are wrong here - you could implement the algorithm incorrectly. If you don't test it, we don't know if it is working. Also, someone later could come in, make a change (accidentially remove a negative sign by hitting the backspace) and the algorithm no longer works.
In your exmple above, I would re-write the test like this to get rid of the calculation: