docs: code coverage rules documented in ADR #3

README.md

@@ -33,7 +33,6 @@ The project repositories are structured as follows:
 - [iroco2-lambdas](https://github.com/ippontech/iroco2-lambdas): The lambda functions repository.
 - [iroco2-terraform-modules](https://github.com/ippontech/iroco2-terraform-modules): The terraform modules repository.
 
-
 ## 📄 Documentation
 
 See the general documentation website [here](https://ippontech.github.io/iroco2/#/).
@@ -45,4 +44,4 @@ See [docs/](./docs) for architecture and technical decisions.
 If you have any questions or need support, please check if this problem has already been reported in the [issue tracker](https://github.com/ippontech/iroco2/issues). If not, please [create an issue](https://github.com/ippontech/iroco2/issues/new/choose).
 
 ## 🤝 Contributing
-See [CONTRIBUTING.md](./contribute/CONTRIBUTING.md)
+See [CONTRIBUTING.md](./contribute/CONTRIBUTING.md)

contribute/CONTRIBUTING.md

@@ -45,7 +45,12 @@ gitGraph
 	commit id: "C6"
 ```
 
-## 3. Commit Messages
+
+## 3. Testing standards
+
+A frame of standards have been designed and documented on [003_tests_standards.md](./contribute/adr/003_tests_standards.md).
+
+## 4. Commit Messages
 
 We use [Conventional Commits](https://www.conventionalcommits.org/) for commit messages, with the id of the corresponding ticket.
 
@@ -58,7 +63,7 @@ feat(auth): #789 implements login with email and password
 It is checked in our Continous Integration.
 To avoid surprised rejects, you can install [pre-commit](https://pre-commit.com) on your personal environment of development.
 
-## 4. Branch Naming Convention
+## 5. Branch Naming Convention
 
 We follow the [Conventional Branches](https://conventional-branch.github.io/) naming convention to ensure clarity, traceability, and automation.
 
@@ -90,13 +95,13 @@ docs/77-update-readme-instructions
 - `release`: For branches preparing a release (e.g., release/v1.2.0)
 - `chore`: Maintenance tasks
 
-### 4.1. Why This Convention Matters
+### 5.1. Why This Convention Matters
 
 - 🔍 **Clarity**: It’s easy to understand the purpose of a branch.
 - 🔗 **Traceability**: The issue number links code to its discussion and context.
 - ⚙️ **Automation**: Tools like `commit-check` and `commit-check-action` can verify branch names and enforce consistency.
 
-## 5. Merge convention
+## 6. Merge convention
 
 In the project, the pull request will be rebased and merge fast-forward.
 
@@ -133,7 +138,7 @@ gitGraph
 	commit id: "C3+C5"
 ```
 
-## 6. Tools & Checks
+## 7. Tools & Checks
 
 To help enforce the rules, we use:
 
@@ -144,6 +149,6 @@ To help enforce the rules, we use:
 
 These tools will validate branch names and commit messages during pull requests.
 
-## 7. Need Help?
+## 8. Need Help?
 
 If you have any questions or need assistance, feel free to open an issue or join the project discussion board. We’re happy to help!

contribute/adr/003_tests_standards.md

@@ -0,0 +1,109 @@
+# Definition of standards for testing
+
+## Context and Problem Statement
+
+As any application, we want IroCO2 to be reliable throughout time. To that end, tests should be written all along code writing, but those tests should not depend on the person who write code. Thus, a definition of standards appears to be mandatory for two reasons : 
+ - this will facilitate test writing, as well as test reviewing
+ - this will ensure the application is resilient, and prevent any regression to be silently implemented
+
+The frame we drew with standards to be respected is settled upon two lines of conduct : code coverage as an indicator, and test strategy as a mindset.
+
+---
+
+## 1. Code coverage
+
+The definition of standards around coverage was mainly based on experience and knowledge of the Ippon Technology team in place at the moment of said definition. Nevertheless, online resources can easily be found if you wish to deepen your comprehension of these rules definition (see for example the article ["What is code coverage"](https://www.atlassian.com/continuous-delivery/software-testing/code-coverage)).
+
+### Objectives for code coverage by perimeter
+
+Since each side of IroCO2 application has its specificities, minimal coverage rate was established project by project. 
+
+Please keep in mind, in particular for Back-end and Front-end projects, that coverage philosophy of IroCO2 team go beyond quantity of tests, thinking also about **quality** and **pertinence** of each test.
+
+| Perimeter      | Objective |
+| -------------- | --------- |
+| Infrastructure | 50%*      |
+| Back-end       | 90%       |
+| Front-end      | 80%**     |
+
+> \* : *indicative value which reflect the ambition to test main components with Terraform Test*
+> 
+> \*\* : *defined without clear idea of necessary time to catch up on that objective, so it can be considered as a minimal*
+
+---
+
+## 2. Test strategy
+
+The main idea behind our test strategy is the Test Pyramid, whose base is made of Unit tests, End-to-end tests at the top, with Integration tests between (see this [pragmatic article](https://martinfowler.com/articles/practical-test-pyramid.html) of Martin Fowler). 
+
+Still, the concrete strategy must match the reality of the project IroCO2, and moreover it seems necessary to define what we mean with unit tests, integration tests or end-to-end tests, for each perimeter.
+
+---
+
+### 2.a. Infrastructure
+
+#### UNIT testing
+
+- Definition
+> Testing infrastructure elements 
+- Strategy
+> Testing of main elements using a combination of Terraform Test, variable validation, pre/post conditions as well as check blocks.
+
+#### INTEGRATION testing
+
+- Definition
+> Testing infrastructure elements 
+- Strategy
+> Testing of main elements using a combination of Terraform Test, variable validation, pre/post conditions as well as check blocks.
+
+#### END-TO-END testing
+-  Definition
+> Testing the whole application.
+- Strategy
+> A few tests of use cases, to be executed on an AWS sandbox account (e.g. Ippon's one) to run a `terraform apply` on the whole stack. Automation can be implemented for Continuous Delivery on non production environment, based on the fork of the github repo.
+
+---
+
+### 2.b. Back-end
+
+#### UNIT testing
+-  Definition
+> Testing the classes individually, mocking anything which could be outside its scope.
+- Strategy
+> Our ambition is to test every possible output of every method of every classe. **The coverage with unit tests should never decrease due to a new development**. When possible, it should rise with new unit tests for existing classes with missing test cases. 
+> Also, an ambition of IroCO2 team is to produce back-end code with TDD.
+
+#### INTEGRATION testing
+-  Definition
+> Testing the components in a more complex way. Some (but not all) external behavior are mocked.
+- Strategy
+> For a given use case, several scenarii should be tested, including errors handling.
+
+#### END-TO-END testing
+-  Definition
+> Testing back-end from endpoints to databases and cloud services without mocking anything.
+- Strategy
+> Each endpoint should be tested through two test cases at least : one testing expected behavior, and one testing error handling
+
+---
+
+### 2.c. Front-end
+
+#### UNIT testing
+-  Definition
+> Testing the components individually, mocking what does not depend on its scope.
+- Strategy
+> Our ambition is to test every UI component of the application. **The coverage with unit tests should never decrease due to a new development**. When possible, it should rise with new unit tests for existing components with missing test cases.
+> Also, an ambition of IroCO2 team is to produce front-end code with TDD.
+
+#### INTEGRATION testing
+-  Definition
+> Testing the components in a more complex way, navigating between components for example
+- Strategy
+> At the moment of the first definition of test strategy, this floor of the Front-end test pyramid is not a priority for IroCO2 team. Anyone is free to init the subject at any moment, beginning with replacing content of this field with the strategy for integration tests.
+
+#### END-TO-END testing
+-  Definition
+> Testing the whole application.
+- Strategy
+> A few tests of use cases, to be executed on an AWS sandbox account (e.g. Ippon's one) to run a `terraform apply` on the whole stack. Automation can be implemented for Continuous Delivery on non production environment, based on the fork of the github repo.