Andreas Svanberg
a76b317b1c
Currently there is only one class used to add test data; [`DataInitializer`](b9f7dd5a49/core/src/main/java/se/su/dsv/scipro/DataInitializer.java). That class is already very large and causes a lot of merge conflicts when multiple changes are in the pipeline as noted by #109.
This change makes it possible to have multiple classes adding test data so that each change adds its own class and thus there are no conflicts. It also has the benefit of making each class smaller and more self-contained for testing a specific feature.
Some additional infrastructure was added in the form of the `BaseData` and `Factory` (naming improvements notwithstanding) interfaces to help each class add its own test data and re-use common data.
Finally all test data related classes have been moved to their own module so they can be properly excluded when building for production but are included by default while developing.
Fixes #109
## Future work
* Add a mechanism to work with date and time.
Many processes (and therefore service method implementations) rely on the time between certain events. For example a final seminar must be scheduled a set amount of days in advance. In the ideal world, the test data is populated using these service methods to more accurately represent an achievable real world state. Therefore there must be a way to manipulate time when adding test data.
* Add more methods to the `Factory` interface as we discover more common steps that many populators must take.
* Add more base data available through the `BaseData` interface as we discover more common data that many populators need
Care must be taken that this data is final and useful in its base state since populators will rely on that state.
Co-authored-by: Nico Athanassiadis <nico@dsv.su.se>
Reviewed-on: #112
Reviewed-by: Nico Athanassiadis <nico@dsv.su.se>
Co-authored-by: Andreas Svanberg <andreass@dsv.su.se>
Co-committed-by: Andreas Svanberg <andreass@dsv.su.se>
Working with the web GUI (Wicket)
The web GUI is protected by OAuth 2 log in. Run the Docker Compose containers with
docker compose up to start the authorization server to be able to log in.
If you run SciPro in development mode (DEV profile) you will be able to log in as the "default" OAuth 2 user populated in the upper form. If you have other data in your database you will have to use the lower form and specify a valid username in the principal field.
Working with the API
The API is protected by OAuth 2 acting as a resource server verifying tokens using token introspection.
When developing it uses a locally running instance of an
authorization server
that is run inside Docker. It can be started with docker compose -f docker-compose.yml up.
Since there is no frontend to interact with the authorization server there's a helper script in
GetToken.java that can be run directly with java GetToken.java to run through the authorization flow
and get an access token.
Once the token has been obtained go to the Swagger UI to interact with the API. Click the "Authorize" button in the top right and paste the access token to log in.
Code formatting
This project uses prettier-java
to format all Java code. To reformat the code run
./mvnw validate frontend:npm@reformat -pl ..
Yes it's a mouthful but unfortunately the prettier-maven-plugin
does not work due to an outstanding issue.
The formatting is validated by CI, but you should do it beforehand with a simple ./mvnw verify -pl ..
Making IntelliJ format for you
For this to work you also need to have Node.js
installed and configured under Settings -> Language & Frameworks -> Node.js
and the file you're saving must be able to compile otherwise no formatting
can be performed.
Go to Settings -> Language & Frameworks -> JavaScript -> Prettier and then check
Automatic Prettier Configuration, set Run for files to **/*.{java},
and finally check Run on save.
Test servers
All pull requests are automatically deployed to a test server. The URL to the test server will be posted as a comment in the pull request once deployed.
Prepare test data in the DataInitializer class to help others test your changes.
Document (in the pull request) which users to log in as and what to do to see the changes.
If you want to reset the data to its original state you can re-run the "deploy-branch.yaml" workflow at https://gitea.dsv.su.se/DMC/scipro/actions for the branch you want to reset.