If you have been careful to properly isolate the code that has to do with accessing external data, then you can swap actual service calls with mock data mode as easily as you would swap between equivalent providers.

It can prove useful in these different contexts:

Whenever you want to test some specific use case or use scenarios. Check how your application reacts when malformed or incomplete data are returned by the web-service.

When it is still the early stages of application development and services are only available when connected to the company network. If you face the prospect to burn the midnight oil to meet a deadline, mock data give you the opportunity to do it in the comfort of your home.

When it is the very early stages of development. The back-end is still being modified. Services can be unavailable sometimes for hours in a row. With mock data, you switch to them and continue development. Less tension in the team!

Worse! The webservices are incomplete or sometimes return invalid data. You are asked to provide clear information on what the input or output of the webservices should look like. The mock-data mode let you experiment with different data format, until you are confident as to your requirements. You can then send clear instructions to the back-end team. Even better, as your code has been made to work exactly as if the data were returned by the actual webservices, you were able to write unit-tests. If the back-end guy sends you data that break any of the test, the pressure is on them to get their code to work as your application expect.

As can be seen in the screenshot of the Package Explorer within Flash Builder, Test-mock includes a reference to the App/src, service-xmlWidged folder introduced in Part III and a new folder mock-xmlWidged. App/src is required for access to classes that capture Virtual Objects (VOs) used internally. It is also required to run the full application in mock data mode. A reference to service-xmlWidged is required for access to the Provider interface (IArtProvider.as) as well as access to the utility classes that convert xml data to internal VOs (ArtXmlConverter.as).

Test-mock overwrites ArtProvider.as and provide a new class to store the data that capture the input and output to the services.

Note that as the mock project ends up running the exact same application than the main production code, I take the precaution to add a colourful border around the application window. A useful reminder that this is not the actual application and may sometimes act slightly differently.

Because a main application is required within the Test-Mock project (running the Main app from the linked App/src folder doesn't work), it is good practice to use a minimalistic AppLauncher to minimize the risk that some code gets updated in one location but not the other. This trick is explained in Part V.