004-ADR-Integrate-Automated-Testing-into-Development-Process

[Shyam-Sundar-Bharathi]

ADR04: Integrate Automated Testing into Development Process

Context and Problem Statement

One major aspect that Bifoot.js lacks a test-suite, making it into a "spaghetti-code" that's unreliable. As the project grows and evolves, ensuring code quality, reliability, and maintainability becomes increasingly important. Test-driven development would enforce the development of a modularised code which can be unit-tested and considered in end-to-end testing.

Automated testing can help catch bugs early, ensure that new features do not break existing functionality, and improve confidence in code changes. To maximize the effectiveness of testing, we must consider the implications for our architectural design and overall workflow.

Decision Drivers

• Improve code quality by catching bugs early in the development lifecycle.
• Enhance maintainability through consistent testing practices.
• Increase developer confidence in code changes by ensuring functionality is validated through tests.
• Integrate testing seamlessly into the existing CI/CD workflow to facilitate continuous feedback.

Considered Options

1. Implement a structured testing strategy with unit tests, integration tests, and end-to-end tests.
2. Maintain the current ad-hoc testing practices without formal integration.
3. Adopt a single type of testing (e.g., only unit tests) while ignoring integration and E2E tests.

Decision Outcome

Chosen option: "Implement a structured testing strategy with unit tests, integration tests, and end-to-end tests," because it provides a comprehensive approach to improving code quality and reliability. This method ensures that various aspects of the application are tested, facilitating a robust and maintainable codebase.

Consequences

• Good: Improved code quality, as automated testing will help identify issues early in the development process.
• Good: Enhanced maintainability due to the practice of writing tests alongside or before code, promoting modular design.
• Good: Increased development speed over time, as automated tests reduce the need for manual testing and debugging.
• Bad: There may be a learning curve for team members to adapt to the new testing frameworks and TDD practices, impacting initial productivity.
• Neutral: Initial time investment in writing tests may slow down development, but the long-term benefits will outweigh this cost.

Confirmation

This decision will be confirmed through ongoing assessment of testing effectiveness and code quality metrics. We will measure the impact of automated testing on the development process and gather feedback from the team regarding the new testing practices.

Pros and Cons of Other Options

Maintain the current ad-hoc testing practices

• Good: No changes are needed to the existing system; minimal disruption to the current workflow.
• Bad: Performance issues will remain, and potential bugs may go unnoticed, leading to decreased code quality.
• Bad: Reliance on manual testing could increase the likelihood of regression issues and slow down development.

Adopt a single type of testing (e.g., only unit tests)

• Good: Focused testing may lead to quick wins in specific areas.
• Bad: Ignoring integration and E2E tests could result in gaps in coverage, leaving critical interactions untested.
• Bad: This approach may lead to a fragmented testing strategy, making it harder to maintain and evolve the codebase effectively.

[shouhardik]

An important ADR. We can also check code coverage percentage to increase reliability of our code.

[MitchelHsu]

I think integration (service) test might be easier to write in this case. Unit tests require a lot of mocking, and might be harder to write, if we want to do it right.