[Mono-devel-list] Corlib test cases
dave-monolist at earth.li
Thu Jan 22 17:05:10 EST 2004
It would make people feel a lot better about writing patches, and in
fact about writing test cases if the tests all passed. Currently my copy
of the class library has 84 test case failures. I am trying to stamp
these out, but cannot do it all myself, mainly because I am not sure if
the tests or code are wrong.
I have been trying to assign bug numbers to the tests that I can see
Below are my notes on the first 10 that I have gone into in detail. It
would be good if we could get people to take responsibility for fixing
them, and for the ones that I have not assigned bug numbers to, for
working out if they are bugs or not and where the bugs lie.
At least some of the tests that are failing appear to be linked to the
internationalization support. I am using ICU version 2.6.1 in case that
makes a difference.
Please help make the test suite a useful tool, rather than a millstone
it feels like at the moment.
> 1) MonoTests.System.ByteTest.TestToString : Compare failed for Formats1
> String lengths differ. Expected length=4, but was length=2.
> Strings differ at index 2.
> but was:<"0.">
> in [0x00086] (at /home/sheldon/hacking/mono/raw_cvs/mcs/class/corlib/Test/System/ByteTest.cs:197) MonoTests.System.ByteTest:TestToString ()
This is http://bugs.ximian.com/show_bug.cgi?id=53022
"en-us floating point numbers missing decimal part"
Who knows about the ICU culture stuff?
> 2) MonoTests.System.Collections.SortedListTest.TestCapacity3 :
> but was:<16>
> in [0x0001b] (at /home/sheldon/hacking/mono/raw_cvs/mcs/class/corlib/Test/System.Collections/SortedListTest.cs:157) MonoTests.System.Collections.SortedListTest:TestCapacity3 ()
Do we really want this as part of the unit test? Do people rely on the initial
size being consistant?
> 3) MonoTests.System.ConvertTest.TestToDateTime : Unexpected exception at iTest = 2: e = NUnit.Framework.AssertionException: #G02
> expected:<1/1/02 12:00:00 a>
> but was:<1/1/20 12:00:00 a>
> in [0x0004c] (at /home/sheldon/hacking/mono/raw_cvs/mcs/class/corlib/Test/System/ConvertTest.cs:632) MonoTests.System.ConvertTest:TestToDateTime ()
> in [0x000a1] (at /home/sheldon/hacking/mono/raw_cvs/mcs/class/corlib/Test/System/ConvertTest.cs:636) MonoTests.System.ConvertTest:TestToDateTime ()
> 4) MonoTests.System.DecimalFormatterTest.TestFormatStrings : DecF #22
> String lengths differ. Expected length=4, but was length=1.
> Strings differ at index 1.
> but was:<"1">
> in [0x00041] (at /home/sheldon/hacking/mono/raw_cvs/mcs/class/corlib/Test/System/DecimalFormatterTest.cs:82) MonoTests.System.DecimalFormatterTest:TestFormatStrings ()
I think this is another:
> 5) MonoTests.System.DecimalTest2.TestDiv : *** Div: result mismatch for d1=79228162514264337593543950335 i=6 d2=10 j=4 d3=7922816251426433759354395033.5 d3b=7922816251426433759354395034
> Ist:7922816251426433759354395033.5 Soll:7922816251426433759354395034 delta=-0.5 == False
> in [0x00143] (at /home/sheldon/hacking/mono/raw_cvs/mcs/class/corlib/Test/System/DecimalTest2.cs:55) MonoTests.System.DecimalTest2:ReportOpError (string,int,int,System.Decimal,System.Decimal,System.Decimal,System.Decimal)
> in [0x00107] (at /home/sheldon/hacking/mono/raw_cvs/mcs/class/corlib/Test/System/DecimalTest2.cs:321) MonoTests.System.DecimalTest2:TestDiv ()
Unfortunately I don't understand this one. Yes, the MS runtime generates the
expected result, but the value we come up with is correct mathematically.
Can someone who knows more explain this one.
> 6) MonoTests.System.DecimalTest.TestToString : A01 tab.format = 'g')
> String lengths differ. Expected length=9, but was length=8.
> Strings differ at index 1.
> but was:<"-1.2e-05">
> in [0x00f7e] (at /home/sheldon/hacking/mono/raw_cvs/mcs/class/corlib/Test/System/DecimalTest.cs:221) MonoTests.System.DecimalTest:TestToString ()
I think this is another US culture ICU issue. Not sure though.
> 7) MonoTests.System.DecimalTest.TestRound : Round: Round(1.2345,3) != 1.235
> in [0x0033d] (at /home/sheldon/hacking/mono/raw_cvs/mcs/class/corlib/Test/System/DecimalTest.cs:883) MonoTests.System.DecimalTest:TestRound ()
This is to do with bankers rounding. http://bugs.ximian.com/show_bug.cgi?id=37744
> 8) MonoTests.System.Diagnostics.StackFrameTest2.TestGetFileLineNumber : Line number (2)
> but was:<120>
> in [0x00028] (at /home/sheldon/hacking/mono/raw_cvs/mcs/class/corlib/Test/System.Diagnostics/StackFrameTest.cs:159) MonoTests.System.Diagnostics.StackFrameTest2:TestGetFileLineNumber ()
Off by one error in runtime. http://bugs.ximian.com/show_bug.cgi?id=45730
> 9) MonoTests.System.Diagnostics.StackFrameTest2.TestGetFileColumnNumber : Column number (2)
> but was:<0>
> in [0x00028] (at /home/sheldon/hacking/mono/raw_cvs/mcs/class/corlib/Test/System.Diagnostics/StackFrameTest.cs:176) MonoTests.System.Diagnostics.StackFrameTest2:TestGetFileColumnNumber ()
> 10) MonoTests.System.Diagnostics.StackFrameTest3.TestGetFileColumnNumber : Column number (2)
> but was:<0>
> in [0x00028] (at /home/sheldon/hacking/mono/raw_cvs/mcs/class/corlib/Test/System.Diagnostics/StackFrameTest.cs:291) MonoTests.System.Diagnostics.StackFrameTest3:TestGetFileColumnNumber ()
This both appear to be related to the above. We appear to always return 0 as
the column number. Do we intend to fix this?
If you have an apple, and I have an apple, and we exchange appels, then you
and I will each have one apple. But if you have an idea and I have an idea
and we exchange these ideas, then each of us will have two ideas.
- George Bernard Shaw
More information about the Mono-devel-list