Closed GeoffreyHuck closed 5 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 100.00%. Comparing base (
4ee3a9b
) to head (1a496c9
).
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
There apparently a test coverage issue. I'll fix that tomorrow. But it's already reviewable.
The coverage is fixed, it was caused by code that cannot be reached. So I added a (rather dummy) test to reach it.
fixes #1039
Implement rules when strengthening a `require_* field as detailed in #1039
action
enumremoved_due_to_approval_change
in tablegroup_membership_changes
Refactor of the test system
There are two limitations with the test system.
1. Everything is in one file, and it keeps growing
For now, the idea is to split it by modules:
groups
will be defined inapp_language_groups.go
.group_pending_requests
will be defined inapp_language_group_pending_requests.go
.app_language_db.go
.It's a first step, it might be refactored into objects in the future because there are common functionalities between modules.
2. The way we handle default values
To provide a higher degree of abstraction, in many definitions, we define rows in tables that are a requirement of the definition (for example: when we had a member to a group, we also add a row in the user table).
The problem was that the system would put in database the values defined the last time if was defined, directly or indirectly. For example: if we define a group with name
my name
, but a later feature defines the same group with the namedefault name
, the database would containdefault name
.The solution retained is to explicitly declare in the testing system when we set a field:
In this way, values are not redefined at default when there are set.
This also makes it clearer what is defined in the current feature.
Test refactor
Documentation will be added in the devdoc to precise the plans. For now, it has only been made for groups, group pending requests and group membership changes, because those are the modules that were impacted with this PR.
Notes
The changes are large and since the commits are incremental and many refactoring were needed, it might be easier to review everything at once rather than commit by commit. But the commit messages contain all the details if needed.