Output is encoded wrongly?

May 19, 2011 at 8:56 AM

On the command prompt output of StatLight I see this:

Microsoft.VisualStudio.TestTools.UnitTesting.AssertFailedException: Assert.AreEqual failed. Expected:<0>. Actual:<1>.

Which should be:

Microsoft.VisualStudio.TestTools.UnitTesting.AssertFailedException: Assert.AreEqual failed. Expected:<0>. Actual:<1>.

Would make it a lot more readable.

And in the resultsfile I see this:

Assert.AreEqual failed. Expected:&amp;lt;0&amp;gt;. Actual:&amp;lt;1&amp;gt;.

So that is even double encoded. But perhaps this is caused by the fact the the message is already encoded and writing to the resultsfile encodes it yet another time.

Also, it would be nice to add the <?xml version="1.0" encoding="UTF-8"?> tag at the top of the resultsfile.

May 20, 2011 at 5:43 AM
Edited May 20, 2011 at 5:55 AM

That encoding issue has been around since inception (I think). I fixed it in the following commit. https://github.com/staxmanade/StatLight/commit/1d4c4d461b919a3a2a4b8885c52ce5591a20400f

You can grab the latest build from teamcity (check the homepage for a link) and let me know how that goes.

I'll work on adding the <?xml version="1.0" encoding="UTF-8"?> to the top of the results file next.

Hope this helps.

May 20, 2011 at 12:41 PM

Ok, downloaded the code, but wasn't able to build it. Errors about Silverlight 3 and so on.

You wrote I could grab the latest build somewhere (the binaries, I expect), but did not find a link to it).

Perhaps I can get the binaries of the latest build, so that I can test it?

Else I will wait until a new version is published on Codeplex


May 20, 2011 at 2:37 PM

got to http://statlight.codeplex.com (there's a DOWNLOAD link - you can't miss it)

May 20, 2011 at 7:22 PM

Wow, that big regular link didn't get my attention ;-). Was looking at the green Download button at the right.

But I now tested the latest build and saw that this issue was fixed.


May 24, 2011 at 8:21 PM
Edited May 24, 2011 at 9:22 PM

FYI: I just reverted my encoding/decoding fix.

Turns out in some scenarios my fix would cause de-serialization errors and fail to report correctly within StatLight.

It seems that the test framework's assertion message is actually reporting it this way.

I may consider adding a one off hack to detect this and fix it, but for now it's back to the way it used to be.