> 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: