Unit testing and E2E Testing

The ionic-quickstarter project contains two types of tests:

• Unit tests implemented using Karma and Jasmine. The unit tests are in the test/unit folder.
• End-to-end (e2e) tests implemented using Protractor. The e2e tests are in the test/e2e folder.

For both types of tests (unit and e2e) we created only a very limited number of tests. These represent in no way a complete test suite for the app, the goal is just to show how to set up the tooling (Protractor, Karma etc) and to demonstrate some best practices for structuring test code.

Unit Testing

Unit tests are under the test/unit folder. They are organized by AngularJS module, so there is a separate subdirectory per module. For instance, there is a config subdirectory containing the tests for the app.config module, and a mainPage subdirectory containing the tests for the app.mainPage module.

To run the unit tests, simply execute the following command from the project's main directory:

gulp test

This will start the Karma test runner and open a browser window (using Google Chrome by default).

Don't close the browser, if you do you stop the test runner (Karma). By default, Karma will keep running in the background, monitoring continuously for changed files under the test/unit folder and automatically re-executing the changed tests.

Configuration of the Karma test runner

Karma is configure through a karma.conf.js file in the project's base directory.

If you look at the karma.conf.js file supplied with the ionic-quickstarter project you can see how this works. For instance, you specify which app files to load for testing through the files array in the config file.

End to End (E2E) Testing

The project is set up for basic end to end (E2E) testing via Protractor. You can read more about Protractor here.

Machine Setup

Make sure your machine has python installed. Type python in the command line you use for building, and if it is not found, please install python from python.org.

Note that you may also need to add python to your path, especially if you are installing on Windows and running from PowerShell.

You will also need the Java Runtime Environment. Web driver will prompt you to install it, if you don't have it already installed.

If you're on a Mac, make sure you install the JRE from Apple, not Oracle. See here: https://support.apple.com/kb/DL1572

The tests use Google Chrome by default. You can change what browser you use in the protractor.conf.js file, or just make sure you have the Chrome browser installed on the machine you are using to test.

Finally, you don't need to install Protractor globally. The provided Protractor configuration will install a local copy of Protractor, along with any necessary web driver plugins.

Running tests

To run the e2e tests, you need a running instance of your app. By default, the e2e tests currently run against a locally hosted instance of your app i.e. at http://localhost:8100. This can be changed in the protractor.conf.js file.

A typical workflow to run the e2e tests would be to first run the app by calling:

ionic serve

Next, you might want to create a new shell instance (since ionic serve will take over the first shell that you used to serve your app). From the second shell, call:

npm run protractor

Protractor will run all the tests as referenced in protractor.conf.js and will print the results to the console. You will see the browser launch (chrome by default), and all your test scenarios played out just like a user would by interacting with the browser.

Test Structure

The e2e tests are in the test/e2e folder. The recommended approach to write e2e tests is to organize them by user scenario, rather than modules in your code. The e2e tests should emulate user behavior for your most critical scenarios.

Under the test/e2e folder, there are 3 subfolders:

• specs: these are the actual Protractor tests ("specs")
• pages: these are "Page Objects" according to the "Page Object Pattern" (for an explanation see https://www.thoughtworks.com/insights/blog/using-page-objects-overcome-protractors-shortcomings and http://moduscreate.com/protractor-and-page-objects/)
• common: these are reusable utility/library modules to simplify the specs and keep them DRY (see http://pavelbogomolenko.github.io/dry-principles-with-protractor.html)

Using "Page Objects" and "Shared modules" are examples of best practices that help to simplify the actual specs and promote code reuse (avoiding copy-and-paste).

References

Unit Testing

1. https://docs.angularjs.org/guide/unit-testing
2. http://gonehybrid.com/how-to-write-automated-tests-for-your-ionic-app-part-1/
3. http://gonehybrid.com/how-to-write-automated-tests-for-your-ionic-app-part-2/
4. http://www.sitepoint.com/unit-testing-angularjs-services-controllers-providers/
5. http://www.syntaxsuccess.com/viewarticle/comprehensive-guide-to-unit-testing-in-angularjs

Protractor (e2e) testing

1. http://angular.github.io/protractor/#/tutorial
2. http://learn.ionicframework.com/formulas/Protractor/
3. http://gonehybrid.com/how-to-write-automated-tests-for-your-ionic-app-part-3/
4. https://www.thoughtworks.com/insights/blog/using-page-objects-overcome-protractors-shortcomings
5. http://moduscreate.com/protractor-and-page-objects/
6. http://engineering.wingify.com/posts/angularapp-e2e-testing-with-protractor/
7. http://stackoverflow.com/questions/31662828/how-to-access-chromedriver-logs-for-protractor-test/31662935
8. https://spin.atomicobject.com/2014/12/17/asynchronous-testing-protractor-angular/
9. http://pavelbogomolenko.github.io/dry-principles-with-protractor.html
10. http://bridge360blog.com/2015/05/05/improving-protractor-tests-using-shared-functions-and-promises/