From c114946c7e1d3d775cb216e577742d6eb5b1d96a Mon Sep 17 00:00:00 2001 From: Ingolf Kuss Date: Thu, 8 Aug 2024 17:37:54 +0200 Subject: [PATCH 1/9] Update Static Code Requirements --- MODULE_ACCEPTANCE_CRITERIA.MD | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/MODULE_ACCEPTANCE_CRITERIA.MD b/MODULE_ACCEPTANCE_CRITERIA.MD index e0386c2..2f99eeb 100644 --- a/MODULE_ACCEPTANCE_CRITERIA.MD +++ b/MODULE_ACCEPTANCE_CRITERIA.MD @@ -20,7 +20,7 @@ Please see [Before Development](MODULE_EVALUATION_TEMPLATE#before-development) f 1. Module adheres to Community Code of Conduct 1. Module license is compatible with the FOLIO Project 1. Module can be included in existing community build processes -1. Module has robust testing that can run with existing community testing processes +1. Module has robust and fully automated testing procedure supplied and documented by the development team 1. Module can be deployed in the Community’s reference environments without undue burden 1. Module is secure 1. Module is multi-tenant @@ -58,8 +58,9 @@ Please see [Before Development](MODULE_EVALUATION_TEMPLATE#before-development) f * _This is not applicable to libraries_ * Must not depend on a FOLIO library that has not been approved through the TCR process * Gracefully handles the absence of third party systems or related configuration. (3, 5, 12) -* Sonarqube hasn't identified any security issues, major code smells or excessive (>3%) duplication (6); and any disabled or intentionally ignored rules/recommendations are reasonably justified. +* An automated code scannner hasn't identified any security issues, major code smells or excessive (>3%) duplication (6); and any disabled or intentionally ignored rules/recommendations are reasonably justified. * See [Rule Customization](https://dev.folio.org/guides/code-analysis/#rule-customization) details. + * The code scanner may be Sonar (via Jenkins), github Actions or other. The testing algorithm must be set up, maintained and documented by the development team. The tests need to be reproducible by the Community. * Uses [officially supported](https://wiki.folio.org/display/TC/Officially+Supported+Technologies) build tools (3, 5, 13) * Unit tests have 80% coverage or greater, and are based on [officially supported technologies](https://wiki.folio.org/display/TC/Officially+Supported+Technologies)[^1] (3, 4) @@ -68,8 +69,9 @@ Please see [Before Development](MODULE_EVALUATION_TEMPLATE#before-development) f Note: Frontend criteria apply to both modules and shared libraries. * If provided, End-to-end tests must be written in an [officially supported technology](https://wiki.folio.org/display/TC/Officially+Supported+Technologies)[^1] (3, 4) - * -_note: while it's strongly recommended that modules implement integration tests, it's not a requirement_ + * -_note: If the new module works together with existing modules, the team must provide a result of an integration test. * -_note: these tests are defined in https://github.com/folio-org/stripes-testing_ +* Front-end unit tests are written in Jest/RTL and reach at least 80% coverage * Have i18n support via react-intl and an en.json file with English texts (8) * Have WCAG 2.1 AA compliance as measured by a current major version of axe DevTools Chrome Extension (9) * Use the Stripes version of referred on the [Officially Supported Technologies](https://wiki.folio.org/display/TC/Officially+Supported+Technologies) page[^1] (10, 16) @@ -92,8 +94,8 @@ Note: Backend criteria apply to modules, shared backend libraries, and edge modu * All API endpoints protected with appropriate permissions as per the following guidelines and recommendations, e.g. avoid using *.all permissions, all necessary module permissions are assigned, etc. (6) * -_note: read more at https://dev.folio.org/guidelines/naming-conventions/ and https://wiki.folio.org/display/DD/Permission+Set+Guidelines_ * Module provides reference data (if applicable), e.g. if there is a controlled vocabulary where the module requires at least one value (3, 16) -* If provided, integration (API) tests must be written in an [officially supported technology](https://wiki.folio.org/display/TC/Officially+Supported+Technologies)[^1] (3, 4) - * -_note: while it's strongly recommended that modules implement integration tests, it's not a requirement_ +* Integration (API) tests must be written in an [officially supported technology](https://wiki.folio.org/display/TC/Officially+Supported+Technologies)[^1] (3, 4) + * -_note: If the new module works together with existing modules, the team must provide a result of an integration test. * -_note: these tests are defined in https://github.com/folio-org/folio-integration-tests_ * Data is segregated by tenant at the storage layer (6, 7) * The module doesn’t access data in DB schemas other than its own and public (6, 7) From 11a8865937077a249d4796014f7b959dc8c933d0 Mon Sep 17 00:00:00 2001 From: Ingolf Kuss Date: Thu, 8 Aug 2024 17:45:22 +0200 Subject: [PATCH 2/9] Update MODULE_ACCEPTANCE_CRITERIA.MD give examples for code duplication figures, specifiy code smell levels --- MODULE_ACCEPTANCE_CRITERIA.MD | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/MODULE_ACCEPTANCE_CRITERIA.MD b/MODULE_ACCEPTANCE_CRITERIA.MD index 2f99eeb..3948f9b 100644 --- a/MODULE_ACCEPTANCE_CRITERIA.MD +++ b/MODULE_ACCEPTANCE_CRITERIA.MD @@ -61,6 +61,10 @@ Please see [Before Development](MODULE_EVALUATION_TEMPLATE#before-development) f * An automated code scannner hasn't identified any security issues, major code smells or excessive (>3%) duplication (6); and any disabled or intentionally ignored rules/recommendations are reasonably justified. * See [Rule Customization](https://dev.folio.org/guides/code-analysis/#rule-customization) details. * The code scanner may be Sonar (via Jenkins), github Actions or other. The testing algorithm must be set up, maintained and documented by the development team. The tests need to be reproducible by the Community. + * Examples for Code Duplication Detection metrics (i.e. characterstic numbers) can be found [here](https://folio-org.atlassian.net/wiki/spaces/TC/pages/378994737/2024-08-06+Meeting+notes) . + * The metric used for code smells module acceptance is the the highest severity level: + * Sonarqube uses the severity level _High_. + * CodeNarc uses the severity level _Critical_. * Uses [officially supported](https://wiki.folio.org/display/TC/Officially+Supported+Technologies) build tools (3, 5, 13) * Unit tests have 80% coverage or greater, and are based on [officially supported technologies](https://wiki.folio.org/display/TC/Officially+Supported+Technologies)[^1] (3, 4) From 24a18bb932e3336eae981fadfa6efa9e99f6f5f9 Mon Sep 17 00:00:00 2001 From: Ingolf Kuss Date: Thu, 8 Aug 2024 17:50:56 +0200 Subject: [PATCH 3/9] Update MODULE_ACCEPTANCE_CRITERIA.MD --- MODULE_ACCEPTANCE_CRITERIA.MD | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MODULE_ACCEPTANCE_CRITERIA.MD b/MODULE_ACCEPTANCE_CRITERIA.MD index 3948f9b..c840c01 100644 --- a/MODULE_ACCEPTANCE_CRITERIA.MD +++ b/MODULE_ACCEPTANCE_CRITERIA.MD @@ -61,7 +61,7 @@ Please see [Before Development](MODULE_EVALUATION_TEMPLATE#before-development) f * An automated code scannner hasn't identified any security issues, major code smells or excessive (>3%) duplication (6); and any disabled or intentionally ignored rules/recommendations are reasonably justified. * See [Rule Customization](https://dev.folio.org/guides/code-analysis/#rule-customization) details. * The code scanner may be Sonar (via Jenkins), github Actions or other. The testing algorithm must be set up, maintained and documented by the development team. The tests need to be reproducible by the Community. - * Examples for Code Duplication Detection metrics (i.e. characterstic numbers) can be found [here](https://folio-org.atlassian.net/wiki/spaces/TC/pages/378994737/2024-08-06+Meeting+notes) . + * Examples for Code Duplication Detection metrics (i.e. characterstic numbers) can be found [here](https://folio-org.atlassian.net/wiki/spaces/TC/pages/386891824/Examples+of+Code+Duplication+Metrics+and+Code+Smells+Severity) . * The metric used for code smells module acceptance is the the highest severity level: * Sonarqube uses the severity level _High_. * CodeNarc uses the severity level _Critical_. From d6767511647038490bc78294eb590e4cfdd574be Mon Sep 17 00:00:00 2001 From: Ingolf Kuss Date: Thu, 8 Aug 2024 17:53:33 +0200 Subject: [PATCH 4/9] Update MODULE_ACCEPTANCE_CRITERIA.MD --- MODULE_ACCEPTANCE_CRITERIA.MD | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MODULE_ACCEPTANCE_CRITERIA.MD b/MODULE_ACCEPTANCE_CRITERIA.MD index c840c01..bc70a14 100644 --- a/MODULE_ACCEPTANCE_CRITERIA.MD +++ b/MODULE_ACCEPTANCE_CRITERIA.MD @@ -62,7 +62,7 @@ Please see [Before Development](MODULE_EVALUATION_TEMPLATE#before-development) f * See [Rule Customization](https://dev.folio.org/guides/code-analysis/#rule-customization) details. * The code scanner may be Sonar (via Jenkins), github Actions or other. The testing algorithm must be set up, maintained and documented by the development team. The tests need to be reproducible by the Community. * Examples for Code Duplication Detection metrics (i.e. characterstic numbers) can be found [here](https://folio-org.atlassian.net/wiki/spaces/TC/pages/386891824/Examples+of+Code+Duplication+Metrics+and+Code+Smells+Severity) . - * The metric used for code smells module acceptance is the the highest severity level: + * The metric used for code smells module acceptance must be the highest severity level: * Sonarqube uses the severity level _High_. * CodeNarc uses the severity level _Critical_. * Uses [officially supported](https://wiki.folio.org/display/TC/Officially+Supported+Technologies) build tools (3, 5, 13) From fa94c5b26daae87748c06bd78345e68cbd52c1ef Mon Sep 17 00:00:00 2001 From: Ingolf Kuss Date: Fri, 9 Aug 2024 10:11:58 +0200 Subject: [PATCH 5/9] Don't mention FE unit tests twice (only in Shared/Common) --- MODULE_ACCEPTANCE_CRITERIA.MD | 1 - 1 file changed, 1 deletion(-) diff --git a/MODULE_ACCEPTANCE_CRITERIA.MD b/MODULE_ACCEPTANCE_CRITERIA.MD index bc70a14..00021fe 100644 --- a/MODULE_ACCEPTANCE_CRITERIA.MD +++ b/MODULE_ACCEPTANCE_CRITERIA.MD @@ -75,7 +75,6 @@ Note: Frontend criteria apply to both modules and shared libraries. * If provided, End-to-end tests must be written in an [officially supported technology](https://wiki.folio.org/display/TC/Officially+Supported+Technologies)[^1] (3, 4) * -_note: If the new module works together with existing modules, the team must provide a result of an integration test. * -_note: these tests are defined in https://github.com/folio-org/stripes-testing_ -* Front-end unit tests are written in Jest/RTL and reach at least 80% coverage * Have i18n support via react-intl and an en.json file with English texts (8) * Have WCAG 2.1 AA compliance as measured by a current major version of axe DevTools Chrome Extension (9) * Use the Stripes version of referred on the [Officially Supported Technologies](https://wiki.folio.org/display/TC/Officially+Supported+Technologies) page[^1] (10, 16) From 9a6e28f5eb8f810aad68aa59fb845771bc08d0dc Mon Sep 17 00:00:00 2001 From: Ingolf Kuss Date: Tue, 13 Aug 2024 16:49:05 +0200 Subject: [PATCH 6/9] Update MODULE_ACCEPTANCE_CRITERIA.MD --- MODULE_ACCEPTANCE_CRITERIA.MD | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/MODULE_ACCEPTANCE_CRITERIA.MD b/MODULE_ACCEPTANCE_CRITERIA.MD index 00021fe..6b1d3e1 100644 --- a/MODULE_ACCEPTANCE_CRITERIA.MD +++ b/MODULE_ACCEPTANCE_CRITERIA.MD @@ -20,7 +20,7 @@ Please see [Before Development](MODULE_EVALUATION_TEMPLATE#before-development) f 1. Module adheres to Community Code of Conduct 1. Module license is compatible with the FOLIO Project 1. Module can be included in existing community build processes -1. Module has robust and fully automated testing procedure supplied and documented by the development team +1. Module has robust testing that can run with existing community testing processes 1. Module can be deployed in the Community’s reference environments without undue burden 1. Module is secure 1. Module is multi-tenant @@ -60,7 +60,7 @@ Please see [Before Development](MODULE_EVALUATION_TEMPLATE#before-development) f * Gracefully handles the absence of third party systems or related configuration. (3, 5, 12) * An automated code scannner hasn't identified any security issues, major code smells or excessive (>3%) duplication (6); and any disabled or intentionally ignored rules/recommendations are reasonably justified. * See [Rule Customization](https://dev.folio.org/guides/code-analysis/#rule-customization) details. - * The code scanner may be Sonar (via Jenkins), github Actions or other. The testing algorithm must be set up, maintained and documented by the development team. The tests need to be reproducible by the Community. + * The code scanner may be Sonar (via Jenkins), github Actions or other. The results of the code scanning need to be reproducible by the Community. * Examples for Code Duplication Detection metrics (i.e. characterstic numbers) can be found [here](https://folio-org.atlassian.net/wiki/spaces/TC/pages/386891824/Examples+of+Code+Duplication+Metrics+and+Code+Smells+Severity) . * The metric used for code smells module acceptance must be the highest severity level: * Sonarqube uses the severity level _High_. @@ -73,7 +73,7 @@ Please see [Before Development](MODULE_EVALUATION_TEMPLATE#before-development) f Note: Frontend criteria apply to both modules and shared libraries. * If provided, End-to-end tests must be written in an [officially supported technology](https://wiki.folio.org/display/TC/Officially+Supported+Technologies)[^1] (3, 4) - * -_note: If the new module works together with existing modules, the team must provide a result of an integration test. + * -_note: while it's strongly recommended that modules implement integration tests, it's not a requirement_ * -_note: these tests are defined in https://github.com/folio-org/stripes-testing_ * Have i18n support via react-intl and an en.json file with English texts (8) * Have WCAG 2.1 AA compliance as measured by a current major version of axe DevTools Chrome Extension (9) From c3ebd8bb534070f8d13d8e4a9cc480b0fefd1396 Mon Sep 17 00:00:00 2001 From: Ingolf Kuss Date: Tue, 13 Aug 2024 16:51:46 +0200 Subject: [PATCH 7/9] Update MODULE_ACCEPTANCE_CRITERIA.MD --- MODULE_ACCEPTANCE_CRITERIA.MD | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MODULE_ACCEPTANCE_CRITERIA.MD b/MODULE_ACCEPTANCE_CRITERIA.MD index 6b1d3e1..8ed491a 100644 --- a/MODULE_ACCEPTANCE_CRITERIA.MD +++ b/MODULE_ACCEPTANCE_CRITERIA.MD @@ -97,8 +97,8 @@ Note: Backend criteria apply to modules, shared backend libraries, and edge modu * All API endpoints protected with appropriate permissions as per the following guidelines and recommendations, e.g. avoid using *.all permissions, all necessary module permissions are assigned, etc. (6) * -_note: read more at https://dev.folio.org/guidelines/naming-conventions/ and https://wiki.folio.org/display/DD/Permission+Set+Guidelines_ * Module provides reference data (if applicable), e.g. if there is a controlled vocabulary where the module requires at least one value (3, 16) -* Integration (API) tests must be written in an [officially supported technology](https://wiki.folio.org/display/TC/Officially+Supported+Technologies)[^1] (3, 4) - * -_note: If the new module works together with existing modules, the team must provide a result of an integration test. +* If provided, integration (API) tests must be written in an [officially supported technology](https://wiki.folio.org/display/TC/Officially+Supported+Technologies)[^1] (3, 4) + * -_note: while it's strongly recommended that modules implement integration tests, it's not a requirement_ * -_note: these tests are defined in https://github.com/folio-org/folio-integration-tests_ * Data is segregated by tenant at the storage layer (6, 7) * The module doesn’t access data in DB schemas other than its own and public (6, 7) From 368740b5e3737926dd9c55c91f89f94690833ae9 Mon Sep 17 00:00:00 2001 From: Ingolf Kuss Date: Tue, 20 Aug 2024 17:14:55 +0200 Subject: [PATCH 8/9] Update MODULE_ACCEPTANCE_CRITERIA.MD: Formulation of code smells severity levels --- MODULE_ACCEPTANCE_CRITERIA.MD | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/MODULE_ACCEPTANCE_CRITERIA.MD b/MODULE_ACCEPTANCE_CRITERIA.MD index 8ed491a..24bf42a 100644 --- a/MODULE_ACCEPTANCE_CRITERIA.MD +++ b/MODULE_ACCEPTANCE_CRITERIA.MD @@ -62,9 +62,9 @@ Please see [Before Development](MODULE_EVALUATION_TEMPLATE#before-development) f * See [Rule Customization](https://dev.folio.org/guides/code-analysis/#rule-customization) details. * The code scanner may be Sonar (via Jenkins), github Actions or other. The results of the code scanning need to be reproducible by the Community. * Examples for Code Duplication Detection metrics (i.e. characterstic numbers) can be found [here](https://folio-org.atlassian.net/wiki/spaces/TC/pages/386891824/Examples+of+Code+Duplication+Metrics+and+Code+Smells+Severity) . - * The metric used for code smells module acceptance must be the highest severity level: - * Sonarqube uses the severity level _High_. - * CodeNarc uses the severity level _Critical_. + * For code smells _major_ means the highest severity level: + * _High_ for Sonarqube. + * _Critical_ for CodeNarc. * Uses [officially supported](https://wiki.folio.org/display/TC/Officially+Supported+Technologies) build tools (3, 5, 13) * Unit tests have 80% coverage or greater, and are based on [officially supported technologies](https://wiki.folio.org/display/TC/Officially+Supported+Technologies)[^1] (3, 4) From 4f922aaf5eeff85bc7ae7a933194c46554af0420 Mon Sep 17 00:00:00 2001 From: Ingolf Kuss Date: Fri, 13 Sep 2024 09:51:39 +0200 Subject: [PATCH 9/9] Update MODULE_ACCEPTANCE_CRITERIA.MD Drop 3% criterion on duplication --- MODULE_ACCEPTANCE_CRITERIA.MD | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MODULE_ACCEPTANCE_CRITERIA.MD b/MODULE_ACCEPTANCE_CRITERIA.MD index 24bf42a..2b7976f 100644 --- a/MODULE_ACCEPTANCE_CRITERIA.MD +++ b/MODULE_ACCEPTANCE_CRITERIA.MD @@ -58,7 +58,7 @@ Please see [Before Development](MODULE_EVALUATION_TEMPLATE#before-development) f * _This is not applicable to libraries_ * Must not depend on a FOLIO library that has not been approved through the TCR process * Gracefully handles the absence of third party systems or related configuration. (3, 5, 12) -* An automated code scannner hasn't identified any security issues, major code smells or excessive (>3%) duplication (6); and any disabled or intentionally ignored rules/recommendations are reasonably justified. +* An automated code scannner hasn't identified any security issues, major code smells or excessive duplication (6); and any disabled or intentionally ignored rules/recommendations are reasonably justified. * See [Rule Customization](https://dev.folio.org/guides/code-analysis/#rule-customization) details. * The code scanner may be Sonar (via Jenkins), github Actions or other. The results of the code scanning need to be reproducible by the Community. * Examples for Code Duplication Detection metrics (i.e. characterstic numbers) can be found [here](https://folio-org.atlassian.net/wiki/spaces/TC/pages/386891824/Examples+of+Code+Duplication+Metrics+and+Code+Smells+Severity) .