• Status: Proposed
• Authors: Chris McCue
• Deciders: Abyss Team
• Date: 2/6/2024

Context

Our team's existing sprint development workflow seeks to improve software quality and detect bugs earlier. Implementing unit testing can serve this purpose. The expectations, coverage metrics, and the cost of unit test integration in terms of time and resources need to be defined.

Currently, our QE side for automation has created a Test Plan defining automation coverage with existing functional/visual tests. We need to decide whether to create a separate plan for unit testing metric coverage or add new unit test cases to the existing Test Plan.

The unit test coverage needs to be differentiated from the existing functional/visual testing automation to avoid duplication of efforts. Our current automation tests vary from visual snapshot tests to in-browser click interactions, keyboard usage functionality, browser context changes, callback console output assertions, etc.

Decision

Incorporate unit tests into our sprint teams. This implementation will involve several steps:

1. Define Unit Test Metric Coverage and Expectations. File coverage of unit test framework to likely be used, however be aware that 100% file coverage != 100% test coverage.
2. Decide on the Test Framework to use. Popular options include Jest (https://jestjs.io/), Jasmine (https://jasmine.github.io/) and Mocha (https://mochajs.org/).
3. Start off with adding unit tests to new features and components.
4. In time, gradually add more to cover testing gaps in existing code.
5. Incorporate Unit Testing into the Definition of Done.
6. Allocate Additional Time in Sprints for Writing Tests.
7. Add Unit Tests after Core Development work has completed.
8. Set up a Continuous Integration (CI) workflow.
9. Include Unit Tests in Code Reviews.

Plan

1. Training/Education: Provide proper education/communication on writing unit tests, setting up the unit test environment, programming the unit tests, and testing the unit tests to ensure they are working as intended.
2. Measure and Monitor: Regularly review test coverage and aim to incrementally improve it, focusing on the quality of the tests themselves rather than just the coverage.

Alternatives Considered

1. Test Driven Development model: Writing unit tests could precede development work, serving as the guideline for the development work. This alternative is a larger change to the existing development model and may increase time to complete sprint tasks.

Consequences

Pros:

• Early detection of bugs and improved code quality.
• Increased overall test coverage.
• Unit tests can serve as basic code documentation.
• Greater confidence in code refactoring and new feature tasks.
• Skill enhancement for team members.
• Greater role for the entire team in ensuring quality of components.

Cons:

• Reduced sprint velocity due to increased workload on developer task workflow.
• Unit tests may not catch all bugs.
• High unit test coverage can give a false sense of security, since they typically run in a different environment than the full end user product.
• Maintenance overhead as unit test suites grow, which can create a significant maintenance burden.
• Potential for ineffective unit tests if not written correctly.

Future Considerations

• Unit test framework architecture for maximum long term scalability and ease of maintenance.
• Coverage documentation for accurate metrics.

Revision History *

[Include Date and brief overview of discussion that led to a revision within the ADR]

* Use when applicable