API and integration tests

Reason for the unit/integration tests: The only way for WISK to achieve an amazing level of quality if by fully testing the business logic on the API
This means that every business logic we write needs to have a full test suite associated
When writing the tests it’s a good practice to practice BDD and to write the test first and see if fail and then write the code to make it green

Specifically:

• if the code is a simple calculation we write a unit test that doesn’t require any database setup
• for workflows that include multiple entities we need to:
  • we create the test scenario (ex: create the venue, item/item variation, invoice)
  • call the code that we are testing
  • assert that we have achieved the functionality we were looking for
  • tear down the rows we have created (note: at the moment of writing this we don’t clean up the test data)
• if the code that we are touching doesn’t have coverage we need to:
  • first add the tests for the code we’ll be touching
  • second add the test for the functionality added

Infrastructure setup

• When developing we can start the Postgres database using docker-compose (see the API project)
  • alternatively we can install it directly on the machine
• When the code is pushed in Git it will run a GitHub action that will trigger a build
  • the swift build machine has a local postgresql database (also started using a docker-compose)
  • this means that both the local testing and the build testing are done on a local database which makes then as fast as possible

---