Crashes due to improper EnqueueCallback behavior with Silverlight 5

Feb 27, 2012 at 4:58 PM


I've tried this with the latest build of statlight and still see the following issue:

When we start our tests running with statlight, the first test class is constructed twice. Then our first asynchronous test method is run twice. The test method does one EnqueueCallback to initialize things and then a second EnqueueCallback to run the core test. But the initialize callback only runs on one class instance, while the core test callback is run only on the other class instance. Our core test callback assumes the initialize callback has run and so we crash when the core test callback tries to use resources that weren't set up since the initialize callback didn't run.

Any ideas? I don't understand why the test class is constructed twice, and then the callbacks seem to run arbitrarily on different instances of the class. I don't see this behavior if I run the test directly from visual studio.

We have worked around this in some cases by giving every test assembly a dummy non-async test (named AAATestClass with AAATestMethod to make sure it goes first) which does not mind being spun up twice and has no EnqueueCallbacks. But this is problematic for when we want to run only one test, and obviously doesn't feel like a good solution.

Thanks for any ideas/help.

Feb 28, 2012 at 2:49 PM

This one was a bugger, and Is something that I have not spent enough time to understand why the Microsoft Silverlight Testing framework (with the certain configuration that I use) causes this to happen.

I used to have an open issue in the issue tracker for this, but a recent suggestion caused me to try/implement it and for most cases it appears to have resolved this.

If you go the home-page of StatLight there is a link to the build server, go download the latest build and give that a try. 

If you are doing any U.I. tests I have a feeling that this still will not work.

Let me know how it goes :)

Feb 28, 2012 at 2:51 PM

Now I'm confused - I looked at the git commit where I mentioned I implemented this and I don't see how it could work (as the 'hack' is commented out). Just giving you a head up - this may not work yet :)

Feb 28, 2012 at 5:53 PM

Thanks for the info. We noticed there weren't any real changes as well but tried it anyways, and indeed, it does not work yet. You mentioned for U.I. tests you don't think this will work... what exactly constitutes a U.I. test? (Sorry, I'm a little green here...) Our tests do show UI and move things around, but I'm not sure if this is enough to count as a UI test.