Front End Web Testing

A practical configuration for Angular is available in Vokal Seed.

Test Coverage

Front end tests should provide assurance that

• All pages load as expected, generally 200 or 302. 400, 500 series and other 200 series responses may be the expected result for XHR though usually not for an actual HTML page. As much as possible, use click events to navigate to pages to test the navigation does in fact go to the right pages.
• All JavaScript that will show or hide part of the DOM does so.
• All JavaScript form validation works as expected.
• All JavaScript that exercises a web service behaves reasonably. Web service API calls for example should not be HTTP 400 or 500 series and your own processing of that data shouldn't fail.
• All form submissions cause the appropriate actions to occur, the data is saved (or whatever happens on the server) and redirection (if any) is to the expected URL.
• All bug fixes are backed with a test that validates them.

Front end tests should not focus on

• Verifying that the server is providing correct data (the response type and format can be validated, but FE tests don't check server math and database integrity, for example)

Testing Structure

Test suites should provide the following benefits:

• Can be run in any browser
• All tests are written exclusively in JavaScript
• Tests can save screenshots of the browser as needed during testing (Phantom does this)
• Tests can be run at different screen sizes
• Testing can be initiated from and integrate with CI

Testing Structure

• Test suites are written with a BDD dialect like Mocha or Jasmine.
• E2E tests should use WebdriverJS http://webdriver.io/ or something comparable that drives selenium web driver.
• Unit tests may run directly through node without requiring a browser, particularly for node and utility code.
• Tests are generally behavioral, use Selenium to exercise parts of the DOM as though you are a user clicking through the site

Running Tests

Configure scripts in package.json to run tests with simple commands like npm test.

E2E Testing Angular

Use Protractor, there is a complete sample setup in Vokal Seed.

Unit Testing Angular

Use Karma, there is a complete sample setup in Vokal Seed.

Code Coverage Tools

Istanbul should be used to generate code coverage. The configuration for doing so varies based on the test framework but samples for Karma and Protractor are in Vokal Seed.

Testing with BrowserStack Automate

When running E2E tests on Drone, use BrowserStack Automate as there are no browsers installed on Drone.

• Generally, Vokal has this account to run automated tests on the Drone server at build time. We have a limited number of connections available at one time, so use your local browser for testing unless you need to test against a browser that isn't installable on your machine.
• If you do want to use Automate on your machine you will want to add the BrowserStack username and key as environment variables on your machine. The configuration setup for protractor makes injecting them as arguments from the command line super awkward... so do it that way. These are available on the left side of the Automate screen when you login to the BrowserStack website. The node process.env will be looking for BROWSERSTACK_USER and BROWSERSTACK_KEY.
• Automate is more prone to timing out than running directly on your machine. Using generous timeout values is recommended, and you will still probably need to sometimes restart a build due to a timeout.
• You will likely want to continue running Karma with Phantom directly on Drone, as it is faster.
• Certain actions running on Automate are in the context of the remote machine rather than "your" machine. Mainly, if you want to use a input[type=file] to upload a file on Automate, you will have to choose one of the file paths on the remote machine.