DLinq and unit testing
I have been playing around with DLinq lately for unit test research. The May CTP C# 3.0 extensions for the most part work with unit test frameworks like MbUnit and NUnit and runners like td.net. DLinq is another story however, the lack of covariance in C# 3.0 means that you can't treat DLinq tables under their base type. So the thinking goes that rather than pass around DLinq table types it's easier to convert to a ICollection object like an ArrayList and pass to a MbUnit CollectionAssert.Contains. I have no idea what DLinq does to an ArrayList but the same ArrayList with the same data and same types will fail through CollectionAssert.Contains yet pass if created manually. TestDriven.net won't work full stop with DLinq and starts throwing CLR errors. So as it stands your stuck between a rock and a hard place for mixing DLinq with unit testing, it's a shame because I was pretty buzzed at the idea of mixing the two. Maybe when Orcas and .NET 3.0 turn up this will all change but for the time being it's not pretty.
Update:
If we look inside the CollectionAssert.Contains it iterates over the collection and compares to the item you expect. When it does this it treats both items as objects e.g.
value == expected
Where value and expected are fed in as objects. The problem with the dlinq fed array occurs when it compares the two values, despite being strings as the underlying type, despite being the same value they are not being seen as equal. If you look at them in VS during a debug
?value
"Green"
?expected
"Green"
?value==expected
false
Clearly not right, yet if I manually populate the array then they are compared as they should be, why do I feel like Fox Mulder right now.