Test-driven development

The examples we've discussed here so far have been high-level. We should actually write some other unit tests that test for null values, invalid properties, and so on, so that we can find bugs in our code. But, more importantly, we really should test for badly-designed components. The test-driven development (TDD) process is where unit testing shines. TDD is a powerful way of designing software components in an interactive way, so that their behavior is specified through the unit test. TDD helps you write software components that individually behave as designed. With TDD, you can easily refactor your code and it provides a way to document your code as you write it. Ultimately, what's great about TDD is that our components have been designed from the ground up—at the unit level. This way, we can make changes to the component, and as long as we don't change the interface, all other components should have no idea that it has changed. For more information on TDD, see here:

https://msdn.microsoft.com/en-us/library/aa730844(v=vs.80).aspx

Code coverage

As part of your development efforts, you will want to make sure that you test as much of your code as possible. Your ultimate goal is to achieve 100 percent of the methods and properties of your classes, by checking that they execute as expected in your unit tests. While this is a laudable goal, it is sometimes not really feasible given the design of the app and schedule. Regardless, you will want to make sure you checked that every method has been called, every statement has been executed, every branch (the if and case statements) has been executed, and lastly every Boolean expression has been evaluated as true or false. For more information on code coverage with Visual Studio, see here:

https://msdn.microsoft.com/en-us/library/dd537628(v=vs.120).aspx

Unit testing with Windows Store

Now that you've seen some unit testing with the Windows version of ArcGIS Runtime, let's try doing the same thing with a Windows Store version of ArcGIS Runtime.

You will need Windows 8.1 or Windows 10 to complete this exercise:

  1. In Visual Studio, create Unit Test Library, as shown here:
    Unit testing with Windows Store
  2. Add the same code as you did in the Unit Test ArcGIS Runtime of this chapter.
  3. Run the app.

You will note that the following error occurs:

System.Exception: The application called an interface that was marshalled for a different thread. (Exception from HRESULT: 0x8001010E (RPC_E_WRONG_THREAD))

This error occurs because we are trying to run ArcGIS Runtime in a class library, when in fact, it contains controls from Esri.ArcGISRuntime.Controls, which were meant to be run from the main UI thread.

Fortunately, there is a solution to this problem that was developed by Esri.

  1. Open up the Chapter11b project that came with this book. In this project, you'll note a file called HelpersThreadHelper.cs and SetupTestEnvironment.cs. The ThreadHelper class allows you to run the preceding code on the main UI thread. In order for this class to work, it must first be initialized when the assembly loads. The SetupTestEnvironment instance has a static method that is called when the assembly is loaded. It gets the main view's dispatcher, and then initializes it. Once that is done, we can call our code using the ThreadHelper class. Copy ThreadHelper.cs and SetupTestEnvironment.cs to your project. Update namespaces if necessary.
  2. Modify your code as shown here:
    [TestClass]
public async Task GeteRedlineCountAsync_CountFeatures_FiveFeaturesFound()
{
    await ThreadHelper.Run(async () =>
    {

        QueryCountResult results = null;
        Map map = null;

        var table = new ServiceFeatureTable(
        new Uri("http://sampleserver6.arcgisonline.com/arcgis/rest/services/Water_Network/FeatureServer/2"));

        await table.InitializeAsync();
        map = new Map();
        map.Layers.Add(new FeatureLayer(table) { ID = "test" });
            

        var queryTask = new QueryTask(new Uri(table.ServiceUri));
        results = await queryTask.ExecuteCountAsync(new Query("1=1"));

        Assert.AreEqual(5, results.Count);
    });
}
  3. Run the app again and you'll note that the test succeeds without an error.

With this code, you can now unit test your apps that are targeted for Windows Store.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.14.144.108