Page History

...

Checklist for building good tests

•  Integration Tests must be written for any methods/classes which require database access to test.  We feel integration tests are more important than unit tests (and you'll see this in our codebase).
•  Unit Tests must be written for any (public or private) methods/classes which don't require database-level access to test.  For example, a utility method that parses a string should have a unit test that proves the string parsing works as expected.
•  Include tests for different user types to prove access permissions are working. This includes testing as (1) an Anonymous user, (2) an Authenticated User (non-Admin), (3) an Administrator and/or Community/Collection Admin (as necessary).
•  Include tests for known error scenarios & error codes.  If the code throws an exception or returns an 4xx response, then a test should prove that is working.
•  Bug fix PRs should include a test that reproduces the bug to prove it is fixed.  For clarity, it may be useful to provide the test in a separate commit from the bug fix.
•  Every test method must cleanup any test data created. See guidelines below for "Cleaning up test data".
•  Use "context.turnOffAuthorisationSystem()" sparingly, and always follow-up  with a "context.restoreAuthSystemState()" as soon as possible (and in the same test method).  As turning off the authorization system can affect the behavior of tests, only use these methods when you need to create or delete test data.
•  If a test needs to temporarily modify a configuration property's value (in any *.cfg file), see the guidelines below for "Changing configuration properties in tests"

...

Checklist for building good tests

todo

Writing Integration (e2e) Tests

A few quick guidelines on writing Angular end-to-end (e2e) tests using Protractor (and Jasmine):

• All e2e tests should be in the /e2e/src/ directory, per the Angular CLI best practices

Writing Unit (spec) Tests

A few quick guidelines on writing Angular tests using Jasmine:

•  Unit Tests (i.e. specs) must be written for every Angular Component or Service.  In other words, every "*.component.ts" file must have a corresponding "*.component.spec.ts" file, and every "*.service.ts" file must have a corresponding "*.service.spec.ts" file.
•  Integration (e2e) Tests are recommended for new features but not yet required.
•  Include tests for different user types (if behaviors differ per user type). This includes testing as (1) an Anonymous user, (2) an Authenticated User (non-Admin), (3) an Administrator and/or Community/Collection Admin (as necessary).
•  Include tests for known error scenarios.  For example, tests should validate when errors/warnings are expected to appear, and/or validate when buttons are expected to be enabled/disabled.
•  Bug fix PRs should include a test that reproduces the bug to prove it is fixed.  For clarity, it may be useful to provide the test in a separate commit from the bug fix.
•  Art Lowel (Atmire), could you add something here about being careful when writing asynchronous vs synchronous tests? (Is there a good guide we could link to for this?)

Writing Unit (spec) Tests

A few quick guidelines on writing Angular tests using Jasmine:

• Specs are required for all Angular Components, Services and other classes.
• All specs should be placed in the same directory as the Angular Component which they test. The filename should end in ".spec.ts".  For example, the login-page.component.ts has a corresponding login-page.component.spec.ts test file.
• As much as possible/reasonable, follow the Angular Testing Guide, which provides detailed example tests. Jasmine also has good documentation/tutorials on learning to write tests.

Writing Integration (e2e) Tests

A few quick guidelines on writing Angular end-to-end (e2e) tests using Protractor (and Jasmine):

• All e2e tests should be in the /e2e/src/ directory, per the Angular CLI best practices.
• A single e2e test consist of two related files:
  • A Page object (ends in "po.ts") which is a class describing a high level page view, including logic for finding all elements on the page and navigating to the page URL. 
  • An e2e test file (ends in "e2e-spec.ts") which include Jasmine-based tests using the Page object.
• Examples of writing Angular e2e tests can be found in this Introduction to e2e Testing with Angular CLI and Protractor blog post, or by referencing the existing tests in our codebase.
• NOTE: be aware that when e2e tests run, they require using a REST API backend & test data. Therefore in Travis CI, our tests run against a Docker based REST API (preloaded with basic test data) defined in the docker-compose-travis.yml
• Specs are required for all Angular Components
• All specs should be placed in the same directory as the Angular Component which they test. The filename should end in ".spec.ts".  For example, the login-page.component.ts has a corresponding login-page.component.spec.ts test file.
• As much as possible/reasonable, follow the Angular Testing Guide, which provides detailed example tests.  Jasmine also has good documentation/tutorials on learning to write tests.