[Mono-dev] question about System.Web.Extensions unit tests

[Atsushi Eno]

Ok I'm glad to know that you guys recognize it as issue (though you
wouldn't fix the tests). I'll simply disable those tests if there is
no fix for this release-blocking issue by the time we do the next
release. The release process will become clear and present danger at
that time.

("#if !DOTNET" does not make sense; the conditional compilation is
done at compile time, not run time. We don't have such switch
anyways. See mcs/class/README for the expected switches.)

Atsushi Eno


Noam Lampert wrote:
> I agree that the tests need modification. 
> There is no intention of compelling Mono to fail, and there are plenty
> of solutions that Mono should pass the tests. I described some below.
> 
> However, having an #ifdef in the tests does not mean that we (Mono and
> Grasshopper) are "kept away from it INCORRECTLY because of #if
> TARGET_JVM THAT DOES NOT PASS ON .NET". On the contrary, it means that a
> human being reviewed the difference between Mono and .NET, clearly
> marked the difference in the code of the test, and decided that this
> difference is acceptable. It is far better than creating tests that pass
> on Mono and fail on .NET.
> 
> Noam
> 
> -----Original Message-----
> From: Atsushi Eno [mailto:atsushi at ximian.com] 
> Sent: Monday, June 02, 2008 5:12 PM
> To: Noam Lampert
> Cc: mono-devel-list
> Subject: Re: [Mono-dev] question about System.Web.Extensions unit tests
> 
> Hello,
> 
> That is very strange argument. Do you understand that your way of
> testing compelling Mono to fail while you guys are kept away
> from it INCORRECTLY because of #if TARGET_JVM THAT DOES NOT PASS
> ON .NET? I regard it as inappropriate practice and strongly suggest
> to rewrite those tests.
> 
> Atsushi Eno
> 
> Noam Lampert wrote:
>> Hi Atsushi,
>>
>> We care about .NET. Please do not rewrite the tests to fail on .NET.
>> Passing on .NET gives strong confidence that our implementation is
>> correct, and not only non-regressive.
>>
>> As you can see, the order of the members in Grasshopper and .NET is
>> different and hence the #if.
>>
>> The best way to fix these tests is to have a strong comparison engine
>> that will understand that these specific differences are not
> important,
>> but this is not a small task.
>>
>> Perhaps a simpler workaround is to succeed on either of the strings
>> (e.g. Assert.IsTrue(script == res1 || script == res2); ).
>> Another alternative is to change the #if TARGET_JVM to #if !DOTNET.
>>
>> Noam
>>
>> -----Original Message-----
>> From: Atsushi Eno [mailto:atsushi at ximian.com] 
>> Sent: Monday, June 02, 2008 3:51 AM
>> To: mono-devel-list at lists.ximian.com
>> Subject: [Mono-dev] question about System.Web.Extensions unit tests
>>
>> Hello,
>>
>> I have been seeing NUnit test failures in Sys.Web.Extensions. It keeps
>> the buildbot orange (warned), so today I checked the tests to see
>> what should be expected.
>>
>> There I found that such lines that treats TARGET_JVM as different:
>>
>> --------
>> #if TARGET_JVM
>> 			Assert.AreEqual ("$create(My.Type, null, null,
>> {\"myName2\":\"myCompId2\",\"myName1\":\"myCompId1\"},
>> $get(\"Element1\"));", script);
>> #else
>> 			Assert.AreEqual ("$create(My.Type, null, null,
>> {\"myName1\":\"myCompId1\",\"myName2\":\"myCompId2\"},
>> $get(\"Element1\"));", script);
>> #endif
>> --------
>>
>> Though I see no reason to differentiate tests for GH. To my
>> understanding from our meeting at Mono summit 2006 time, Mainsoft
>> does not use #if TARGET_JVM without any reasonable differences,
>> so I would like to know the reason why there are such switches all
>> around the tests so that they can pass on GH while they will fail
>> on Mono, if any.
>>
>> Actually when I ran make PROFILE=net_3_5 run-test-ondotnet, there
>> was no error report. So if those tests are rewritten, they will
>> fail on .NET.
>>
>> If it is only about behavioral difference in generic Dictinary`2,
>> then those tests should not be conditionalized to legalize only in
>> TARGET_JVM and rewritten to fail only on .NET. (Who cares after all?)
>>
>> Atsushi Eno
>>
>>
> 
>