Visual Studio Unit Test: why test run inconclusive whereas testing same float values?

12,591

Solution 1

erm, because you told it to be?

Assert.Inconclusive("Verify the correctness of this test method.");

Now you have your AreEqual, you should be able to remove this Inconclusive

Any failure during a test (not including exceptions that you intentionally handle) is generally terminal, but any assert that passes (like the AreEqual here) just keeps on running. So the first test passes, then the last line flags it as inconclusive.

Solution 2

Even when you've removed the Assert.Inconclusive you still might have problems.

You're testing the equality of two floating point numbers and in general with calculated values you'll never get them exactly the same. You need to check that the actual value is within an acceptable range of the expected value:

Math.Abs(actual - expected) < 0.00001;

for example.

Your Assert.AreEqual(expected, actual); works in this case because you are assigning the same value to both variables.

Solution 3

Doesn't that just mean that the AreEqual passed, which meant it called Assert.Inconclusive, leading to a result of inconclusive?

From the docs:

Similar to Fail in that it indicates an assertion is inconclusive without checking any conditions.

If you don't want the result to be inclusive, remove the call to Assert.Inconclusive :)

Solution 4

The automatic UnitTest is generated by VS and tells you to create some operations to compare. if you'll comment the last Assert command you will get "Passed" with green mark, but you didn't test it.
You need, as in the comment, "Initialize to an appropriate value" and as in the last Assert "Verify the correctness of this test method".
Initialize the expected and the actual values from where they come from for example, Expected is the expected value from function Add(x,y) where x=2 and y=3. Actual value should come from the function. in this case:

// Sample - Start
Expected = 2+3;
Actual = Add(2,3);
Assert.AreEqual(expected, actual);
// Sample - End

Hope it helped, i broke few teeth for that... ;-)

Share:
12,591
user310291
Author by

user310291

nada !

Updated on June 14, 2022

Comments

  • user310291
    user310291 almost 2 years

    I'm learning VS Unit test and tried this:

        [TestMethod()]
        public void calcTest()
        {
            double expected = 1.234F; // TODO: Initialize to an appropriate value
            double actual;
            actual = 1.234F;
            Assert.AreEqual(expected, actual);
            Assert.Inconclusive("Verify the correctness of this test method.");
        }
    

    When running this test method, it says inconclusive ??? Why ?

    Update: Ok to tell don't compare floats, but business requirements are what they are. So what should I do if I need to compare them?

    Do you mean it's impossible to test floating calculation without headache? Then if testing is such a headache in financial calculation isn't it better to not do testing at all?

    Seems like a huge bug or design flaw in vs test framework rather :) as it is said here http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.unittesting.assert.inconclusive%28VS.80%29.aspx

    Indicates that an assertion cannot be proven true or false.

    Since I compare 2 same litterals sure it is true.

  • Marc Gravell
    Marc Gravell over 13 years
    Good warning, but in this case he's comparing two variables initialized from literals, so I would expect it to be OK. But +1, definitely a very good point to raise!
  • ChrisF
    ChrisF over 13 years
    @Marc - I spotted that so added a note to that effect.
  • Ani
    Ani over 13 years
    The fact that accurate floating point representations may not exist for certain decimal numbers does not make them 'fuzzy'. The general point about not comparing 2 floats for equality is fine, but it does not apply in this case: there is no reason that the compiler will choose different double representations for the same float literal.
  • Henk Holterman
    Henk Holterman over 13 years
    Not in this (very artificial case) but in general: Yes, don't compare floats.
  • user310291
    user310291 over 13 years
    What don't compare floats but Business Requirements need to compare float :)
  • user310291
    user310291 over 13 years
    My point is mathematically and from business viewpoint it's sure not inconclusive but conclusive since it is true :)
  • user310291
    user310291 over 13 years
    The problem with testing < 0.00001; is that in the application which covers many countries and brands the precision will vary so It's rather circumvolated because I'll have to create an algo just for calculating the threshold for test that sucks :)
  • ChrisF
    ChrisF over 13 years
    @user310291 - you can compare floats - you just need to be careful due to rounding errors and the fact that not all floats can be represented. As long as you allow for this rounding error you should be OK. Also using decimal will reduce the rounding error. My use of 0.00001 was merely meant as an example.
  • user310291
    user310291 over 13 years
    Why Assert.Conclusive doesn't exist ? We're not doing statistical testing where such Inconclusiveness would be sensical, this is deterministic testing where testing result will be yes or no.
  • user310291
    user310291 over 13 years
    I think you're right but the template should not put this as default in code snippet because this is very confusing.
  • user310291
    user310291 over 13 years
    Assert.Inconclusive Method Indicates that an assertion cannot be proven true or false.
  • user310291
    user310291 over 13 years
  • user310291
    user310291 over 13 years
    What's the exact syntax I can't see any Assert.IsLessThan ? Thanks.
  • ChrisF
    ChrisF over 13 years
    @user310291 You'll have to use the Assert.IsTrue method, passing the test as the argument. See msdn.microsoft.com/en-us/library/ms243771(v=VS.80).aspx
  • Jeroen Wiert Pluimers
    Jeroen Wiert Pluimers about 12 years
    @user310291 from a testing perspective, this is not confusing. All tests fail until you either write the correct test (and remove the inconclusive part) or you fix the code-to-be-tested.