Quality

operable

  • Migrations correctly migrate from previous version to the current one, without losing data etc. (within dev migrations can be modified or squashed).
  • Frontend+backend are (re)-deployed together, so there cannot be version mismatches.
  • Only a minimal set of configuration options and everything is configurable only via .env.
  • Everything builds and runs on Linux and the CI.

usability

  • Compliance with UI style-guide.
  • Easily understandable acceptance test cases.
  • Usability tests with own case studies and gardeners.
  • (Future) Usable despite color blindness.
  • (Future) Usable with tablet gloves.

efficient

  • At least 3000 users should be able to use the backend simultaneously.
  • Startup time of backend should be less than one second.
  • Near instant search results.
  • Good carbon emission efficiency.

secure

  • Avoid common vulnerabilities
  • Use reliable software for security concerns
  • Everything encrypted (https)
  • Only encrypted or local storage
  • Only authenticated users can access non-public data

flexible

One of our least important goals. Users or programmers do not need simple ways to extend PermaplanT or to change features. The only quality requirement we have are:

  • usage in different browsers, including tablets
  • localized to German and English

Backend Tests

Tests are split into unit and integration tests (see here for reference).

Integration tests can be found here.
Unit tests can be found in the modules they are supposed to test.

Code documentation

The code documentation of the backend can be built using cargo doc --open.

You can find a more detailed explanation of which modules do what there.

API documentation

The API documentation can be viewed by running the backend with cargo run and then navigating to http://localhost:8080/doc/api/swagger/ui/.
It is automatically built using utoipa.

Frontend Code Documentation

The code in the frontend is documented by two different mechanisms. On the one hand components are documented via storybook, on the other hand the public API of a feature, shared hook or utility, etc. should be documented by doc comments. We use TypeDoc to extract the documentation from code comments. More details about supported tags and syntax can be found in the TypeDoc documentation.

The code documentation of the frontend can be generated via the command npm run doc. Under the hood, this command executes TypeDoc that generates .mdx files to be viewed in storybook.

Afterwards it can be opened in storybook via the command npm run storybook.

More details about documentation can be found in the contribution docs