Testing Strategy 1.0

[hcarreras]

This is meant to be a conversation starter, rather than the final implementation.

[gemini-code-assist]

Summary of Changes

Hello @hcarreras, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces an initial draft of Abtion's comprehensive testing strategy, intended to serve as a conversation starter for defining company-wide testing expectations. It replaces a more specific document on Test-Driven Development with a broader framework that covers general testing principles, CI requirements, and specific guidelines for both backend and frontend development.

Highlights

• Documentation Update: The previous document on Test-Driven Development (TDD) has been removed to make way for a more comprehensive testing strategy.
• New Testing Strategy Introduced: A new testing_strategy.md document has been added, outlining Abtion's expectations and requirements for testing across all projects.
• General Testing Expectations: The new strategy mandates end-to-end (e2e) tests for all critical flows, requires new tests for every bug fix to prevent regression, and enforces a strict 'CI cannot merge if red' policy.
• Backend Test Coverage: An 80% test coverage is now enforced as a CI rule for backend code, with coverage gates blocking merges if not met.
• Frontend Test Coverage and Approach: Frontend requires 80% test coverage for utilities, validation logic, and data mapping functions. It also specifies an approach to avoid unit testing UI implementation details, focusing instead on component logic, state management, and business logic.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Changelog

• technical_practices/tdd_testdriven_development.md
  • Removed the previous document detailing Test-Driven Development (TDD).
• technical_practices/testing_strategy.md
  • Introduced a new document outlining Abtion's comprehensive testing strategy.
  • Defined general expectations including end-to-end tests for critical flows, mandatory tests for bug fixes, and strict CI merge requirements.
  • Specified an 80% test coverage requirement for backend code.
  • Outlined frontend testing requirements, including 80% coverage for utilities, validation, and data mapping, and a focus on testing component logic over UI unit tests.

Activity

• This pull request is an initial proposal for a new testing strategy, presented by hcarreras.
• The author explicitly states this is a 'conversation starter' rather than a final implementation, indicating it's ready for discussion and feedback.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a new, comprehensive testing strategy document, replacing the previous one focused on TDD. The new guidelines are clear and set solid expectations for testing across projects, including rules for critical flows, bug fixes, CI/CD, and test coverage for both backend and frontend. My review focuses on improving the clarity and conciseness of the new documentation to make the rules even more effective and less open to misinterpretation. The suggestions aim to reduce redundancy and refine some of the phrasing.

[gemini-code-assist]

These two statements are slightly redundant. The first statement, 'CI cannot merge if red — this is non-negotiable', already implies that all tests must pass. You could combine them for conciseness and impact.

Suggested change

	**CI cannot merge if red** — this is non-negotiable.
	All tests must pass before code can be merged. No exceptions.
	**CI pipelines must pass before merging.** A failing (red) pipeline is a hard block, and this rule is non-negotiable.

[gemini-code-assist]

These two points are redundant. 'Enforced as a CI rule' already implies that mandatory coverage gates will block merges. You can combine them into a single, more concise point.

Suggested change

	- **80% test coverage** is enforced as a CI rule
	- Coverage gates are mandatory and will block merges if not met
	- A minimum of **80% test coverage** is enforced through mandatory CI gates that block merges if the threshold is not met.

[gemini-code-assist]

The statement 'Don't unit test the UI' is very absolute and could be misinterpreted. While the intent to avoid testing implementation details is correct, this phrasing might discourage valuable component-level testing. Consider rephrasing to emphasize testing behavior over implementation, which seems to be the core message of these two points.

Suggested change

	- **Don't unit test the UI** — avoid testing implementation details of visual components
	- **Test component logic** — focus on behavior, state management, and business logic within components
	- **Test behavior, not implementation details.** UI tests should focus on what the component does from a user's perspective (behavior, state changes, business logic) rather than its internal structure. This creates more robust and less brittle tests.