From 1cc3bffc5ce68459d2a3a90ce359f1fcad507c55 Mon Sep 17 00:00:00 2001 From: geenag <27012568+Geenag@users.noreply.github.com> Date: Mon, 29 Sep 2025 11:59:33 +0200 Subject: [PATCH 1/5] docs: test coverage rules documented in ADR #3 --- README.md | 4 ++++ contribute/adr/003_tests_standards.md | 33 +++++++++++++++++++++++++++ 2 files changed, 37 insertions(+) create mode 100644 contribute/adr/003_tests_standards.md diff --git a/README.md b/README.md index 377fcc7..5f02ce5 100644 --- a/README.md +++ b/README.md @@ -33,6 +33,10 @@ 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. +## βœ… Testing + +A frame of standards have been designed and documented on [003_tests_standards.md](./contribute/adr/003_tests_standards.md). + ## πŸ“„ Documentation diff --git a/contribute/adr/003_tests_standards.md b/contribute/adr/003_tests_standards.md new file mode 100644 index 0000000..f4b8843 --- /dev/null +++ b/contribute/adr/003_tests_standards.md @@ -0,0 +1,33 @@ +# 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, 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 project + +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. + +| Project perimeter | Source code opening | Long-term objective | +| ----------------- | ------------------- | ------------------- | +| Infrastructure | 0% | 50%* | +| Back-end | 80% | 90% | +| Front-end | 50%** | 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 + +To be done. From 355cc23bcc1984f6b93d0dce0f2c0c589af31bae Mon Sep 17 00:00:00 2001 From: Victor LUCE <27012568+Geenag@users.noreply.github.com> Date: Mon, 29 Sep 2025 16:16:20 +0200 Subject: [PATCH 2/5] docs: update README.md in order to be consistent with README.md from back-end --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 5f02ce5..5af0c91 100644 --- a/README.md +++ b/README.md @@ -33,7 +33,7 @@ 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. -## βœ… Testing +## βœ… Testing standards A frame of standards have been designed and documented on [003_tests_standards.md](./contribute/adr/003_tests_standards.md). @@ -49,4 +49,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) \ No newline at end of file +See [CONTRIBUTING.md](./contribute/CONTRIBUTING.md) From a1d7fb1e28e3cafb14befd09b675729a01064748 Mon Sep 17 00:00:00 2001 From: Victor LUCE <27012568+Geenag@users.noreply.github.com> Date: Tue, 30 Sep 2025 15:32:27 +0200 Subject: [PATCH 3/5] docs: retours PR --- README.md | 5 ----- contribute/CONTRIBUTING.md | 17 +++++++++++------ contribute/adr/003_tests_standards.md | 12 ++++++------ 3 files changed, 17 insertions(+), 17 deletions(-) diff --git a/README.md b/README.md index 5af0c91..56ea294 100644 --- a/README.md +++ b/README.md @@ -33,11 +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. -## βœ… Testing standards - -A frame of standards have been designed and documented on [003_tests_standards.md](./contribute/adr/003_tests_standards.md). - - ## πŸ“„ Documentation See the general documentation website [here](https://ippontech.github.io/iroco2/#/). diff --git a/contribute/CONTRIBUTING.md b/contribute/CONTRIBUTING.md index 0549d3d..4b11cae 100644 --- a/contribute/CONTRIBUTING.md +++ b/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! diff --git a/contribute/adr/003_tests_standards.md b/contribute/adr/003_tests_standards.md index f4b8843..36cee20 100644 --- a/contribute/adr/003_tests_standards.md +++ b/contribute/adr/003_tests_standards.md @@ -12,17 +12,17 @@ The frame we drew with standards to be respected is settled upon two lines of co 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 project +### 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. -| Project perimeter | Source code opening | Long-term objective | -| ----------------- | ------------------- | ------------------- | -| Infrastructure | 0% | 50%* | -| Back-end | 80% | 90% | -| Front-end | 50%** | 80% | +| Perimeter | Objective | +| -------------- | --------- | +| Infrastructure | 50%* | +| Back-end | 90% | +| Front-end | 80%** | > \* : *indicative value which reflect the ambition to test main components with Terraform Test* > From 8eeba6d2747a7988fa9d9de7ae106399abcb519b Mon Sep 17 00:00:00 2001 From: geenag <27012568+Geenag@users.noreply.github.com> Date: Wed, 1 Oct 2025 14:42:11 +0200 Subject: [PATCH 4/5] docs: adr test strategy --- contribute/adr/003_tests_standards.md | 83 +++++++++++++++++++++++++-- 1 file changed, 79 insertions(+), 4 deletions(-) diff --git a/contribute/adr/003_tests_standards.md b/contribute/adr/003_tests_standards.md index 36cee20..5a2397d 100644 --- a/contribute/adr/003_tests_standards.md +++ b/contribute/adr/003_tests_standards.md @@ -2,21 +2,23 @@ ## 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, definition of standards appears to be mandatory for two reasons : +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)) +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. +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 | | -------------- | --------- | @@ -28,6 +30,79 @@ Please keep in mind, in particular for Back-end and Front-end projects, that cov > > \*\* : *defined without clear idea of necessary time to catch up on that objective, so it can be considered as a minimal* +--- + ## 2. Test strategy -To be done. +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 + +For infrastructure perimeter, unit testing and integration testing appear to be difficult. Thus, infrastructure code will mostly be tested with End-to-end tests, focusing on the top of the test pyramid : + +#### UNIT testing + +- Definition +> Testing infrastructure elements +- Strategy +> Testing of main elements using for example Terraform Test + +#### INTEGRATION testing + +Not applicable + +#### END-TO-END testing +- Definition +> Testing the whole application. +- Strategy +> A few tests of use cases, to be executed manually at first, within an AWS sandbox running IroCO2 code. Automation shall be implemented in a second phase. + +--- + +### 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 manually at first, within an AWS sandbox running IroCO2 code. Automation shall be implemented in a second phase. \ No newline at end of file From 5c02a34d5808f1b33d0ada5faa9999ebda89267a Mon Sep 17 00:00:00 2001 From: Victor LUCE <27012568+Geenag@users.noreply.github.com> Date: Wed, 22 Oct 2025 10:55:06 +0200 Subject: [PATCH 5/5] docs: retours PR 2 --- contribute/adr/003_tests_standards.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/contribute/adr/003_tests_standards.md b/contribute/adr/003_tests_standards.md index 5a2397d..b88571a 100644 --- a/contribute/adr/003_tests_standards.md +++ b/contribute/adr/003_tests_standards.md @@ -42,24 +42,25 @@ Still, the concrete strategy must match the reality of the project IroCO2, and m ### 2.a. Infrastructure -For infrastructure perimeter, unit testing and integration testing appear to be difficult. Thus, infrastructure code will mostly be tested with End-to-end tests, focusing on the top of the test pyramid : - #### UNIT testing - Definition > Testing infrastructure elements - Strategy -> Testing of main elements using for example Terraform Test +> Testing of main elements using a combination of Terraform Test, variable validation, pre/post conditions as well as check blocks. #### INTEGRATION testing -Not applicable +- 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 manually at first, within an AWS sandbox running IroCO2 code. Automation shall be implemented in a second phase. +> 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. --- @@ -105,4 +106,4 @@ Not applicable - Definition > Testing the whole application. - Strategy -> A few tests of use cases, to be executed manually at first, within an AWS sandbox running IroCO2 code. Automation shall be implemented in a second phase. \ No newline at end of file +> 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.