Upgraded to Silverlight 5 and now the very first test fails regardless of which test it is.

May 11, 2012 at 8:26 AM
Edited May 11, 2012 at 8:29 AM

We've just upgraded our project to Silverlight 5 and the latest version of StatLight and the tests that previously worked OK with Silverlight 4 and the previous version of StatLight are now giving us this problem.

All the test classes are constructed to the same structure. We have a `[TestInitialize]` method that constructs the view to be used for the test:

protected FrameworkElement TargetView { get; set; }

[TestInitialize]
public void TestInit()
{
    // Construct data to be used for test
    TargetView = CreateView(...);
}

Then each `[TestMethod]` follows the same pattern where the UI element to be tested is found before the bindings are verified and exercised:

[TestMethod]
[Description("Tests that the active CheckBox is data bound correctly")]
[Tag("CommunityCenter")]
public void TestActiveCheckBoxBinding()
{
    var activeCheckBox = GetUIElement("chkActive");
    // The rest of the test
}

protected T GetUIElement<T>(string name) where T : UIElement
{
    return (T)TargetView.FindName(name);
}

It's this method that's failing because `TargetView` is `null`. It looks like the actual test is being called before the test initialisation is complete. At first we thought it was the specific test, but removing the test or even the whole test class just shifted the problem to the new first test. The next test, which is constructed in exactly the same way works.

At the moment to get round this issue we've created a dummy first test that has a `try...catch` block around a call to `GetUIElement` to ensure that it never fails. The rest of the tests run as expected.

The project is based on Prism 4.

Coordinator
May 11, 2012 at 8:10 PM

Thanks for the great report. I'm afraid this is due to a bug in the MSFT Testing framework and we don't have a good resolution to the problem at this point.

Let me know if you find any good work-arounds.

May 16, 2012 at 12:14 PM

Thanks for the information.

The work-around we have - using the dummy test - will do for now.