Acceptance testing are stories turned in code. When we scope out a feature, we typically create a user story with acceptance criteria. For example:
As a User, I can export the financial report as a CSV in order to share with my team.
- Verifies I can select the fields I want to export
- Verifies exports to a .csv format
- Verifies a preloader is displayed until completed
Our acceptance tests will verify each of the criteria for a given story. This is how we verify that we've completed a task and all criteria has been accepted. Typically, we write failing test first then write the code for the tests the pass. All of our tests are run through continuous integration before we merge into our codebase or deploy.
Acceptance testing in Ember allows us to interact with an instance of the application in the browser to make sure that all interactions, transitions, and initial page loads render the correct elements to the page
Acceptance tests are usually grouped by route and named after their URL. For example, to generate a test of the login route you would run:
ember g acceptance-test login
If you wanted to generate a test of the users/show route you would run:
ember g acceptance-test users/show
The contents of the tests/acceptance directory should match the app/routes directory to ensure good test coverage.
Try to break you acceptance-test files into separate tests for the main interactions on that page. The first test should always make sure that the page loads properly when navigating to that URL. Invalid page loads should also be tested to make sure they render an error page or flash message
Once navigating to the route has been tested, each major interaction should be fully tested. This will include filling in inputs and clicking on elements to make sure that they make the expected changes to the page. Form submissions, opening modals, and toggling state on the page are all good things to write tests for