Automated testing

Zebble provides automated UI testing support for the final application, whereby you invoke commands on the actual app UI. That style of testing is powerful, because it allows you to test the end to end functionality of the app, including logic and UI in one go. However, there are two problems with that:

1. During ViewModel development, you will typically not have the UI to run the test against.
2. The syntax of such tests is not strongly typed which can lead to unnecessary runtime errors (For example Tap("OK") can fail at runtime because there is no such button).

Those tests are still useful and powerful and should be used. However, you should also write unit tests against the view model alone, even before you have created the UI. This has several advantages:

1. You can start writing tests as soon as the project starts (TDD).
2. You have full strong typing and intellisense.
3. They are quicker and easier to write by simply invoking viewmodel methods and property setters
4. You can focus on the to-the-point logical flow of information irrespective of UI
5. They run much faster and can be executed frequently

Example

In the VM project, there is a folder called Tests.

Each automated test should be a class inside that folder, inheriting from Zebble.Mvvm.TestScript.

Use standard unit testing best practices.

namespace App.Tests
{
    class FailedLoginTest : TestScript
    {
        protected override async Task SetUp()
        {
               // This method is optional. If your test requires any setup work before getting to your main test logic, you can implement it here.
              // In practice, this is more useful when creating helper TestScript base classes, from which your main test classes inherit.
        }

        protected override async Task Execute()
        {
            On<WelcomePage>().TapLogin();
            Expect(On<LoginPage>.SampleProperty == "Blah blah");
            On<LoginPage>.Email.Set("jack@gmail.com");
            On<LoginPage>.TapLogin();
            Expect("Please enter your password.");
            On<LoginPage>.Password.Set("incorrect");
            On<LoginPage>.TapLogin();
            Expect("Invalid password. Try again.");
        }
    }
}As you can in the above example, another overload of the On<ViewModel>() method is used which gives us a shortcut to the view model instance to avoid code duplication.

It serves two purposes:

1. Assert that the app's current active state (view model) is what you specify.
2. Give you strongly typed access to the actual state (view model) object to invoke commands.

If the current screen in the app state is anything other than what you specify as the generic argument of the ON method, then it throws an exception.

Running a test

In VM.exe\Program.cs you can instantiate and run a test using any of the following methods:

class Program
{
    static Intention Doing = Intention.Development;

    public static async Task Main(string[] args)
    {
        Zebble.Console.Configure();
        await ViewModel.StartUp.Run();

        if (Doing == Intention.OneTest) await Test.Run<MyTest>();
        if (Doing == Intention.AllTests) await Test.RunAll();
        if (Doing == Intention.Development) await DevContext.Reach();

        if (args.None()) Zebble.Console.Start(args);
   }
}During development time, you should change Doing to the activity that you are doing there and then:

• OneTest: If you are developing or debugging a single test script, choose this option. Also change MyTest to the actual test.
• AllTests: Choose this option to run all test cases in one go.
• Development: Choose this if you're developing or debugging the view model. It is strongly recommended that you also update the script in the DevContext class to speed you up.

Test pre-conditions / setup

Often your tests will have pre conditions. You can override the SetUp() method in your TestScript classes to execute any pre-condition, so that your test code's Execute() method is semantic, lean, and focused on the actual intention and purpose of the test.

If you want to share a pre-condition in several tests, then create abstract base classes. A common example is to do "login".

/// <summary>
/// Inherit your user tests from this class.
/// </summary>
abstract class LoggedInUser : TestScript
{
    protected override async Task SetUp()
    {
        // TODO: Do the basic user login.            
    }
}

DevContext

In VM.exe project in Visual Studio, you will see a class named DevContext:

using Zebble.Mvvm;

namespace App
{
    abstract class DevContext: TestScript
    {
        // Run quick steps to get you to the context you're developing.
        public static async Task Reach()
        {
            // Run quick steps to get you to the context you're developing.
            On<WelcomePage>().TapLogin();
            On<LoginPage>().TapLogin();
            On<ShoesPage>().Items[0].Tap();
        }
    }
}

This code runs as soon as your VM.exe process starts, during development. Its purpose is to automatically run a few steps to get you to the context you're interested in.

The idea is, that as you're developing an app, you start with a basic starting page and move your way up from there. Every page, or workflow step, is developed, which then allows you to implement the next logical app function. Typically, every time you run an app, you have to take a few actions (button clicks, inputs, etc) on the pages already developed, to finally arrive at the page you're developing, i.e. the "interesting page" at that time.

The Script.cs file is a temporary, working file. It is changed continuously, and does not form a part of the final app. It's purpose is to allow you to automate those steps, and thus get you right at the final page you're currently developing and testing, without wasting time on the repeatable clicks and inputs.