Overhaul Testing: clean up tests, re-use resources and remove unneccesary iterations

[Jonathan-Zollinger]

Summary

Tests need to separated out to tests that can be run quickly and tests that take more time and need less frequent testing.

Unit tests

Unit tests validate minimum functionality and focus on testing the least amount of moving parts necessary. This facilitates giving This and emulating user input data finds any testing aims to validate the published api works as documented.

def "test querying store via store ID throws no error"() { 
    when: "making simple query for store based on store id"
    HttpResponse<StoreLocationRoot> response = threshrClient.getStore(location_id as String)

    then: "no error is thrown"
    noExceptionThrown()

    and: "response body isn't empty"
    null != response.body()

    where:
    location_id << 'select location_id from target_stores'
  }

what a unit test ISNT

• dont test setters and getters unless there's something weird about a field / setter / getter.
  • use something like lombok or records which does the setters and getters (and thus the testing) all for you.

integration tests

There's not a huge opportunity for this in Threshr. as I'm writing this out I dont actually think there is opportunity for this since threshr just regurgitates the resdky api - hmu with a comment here if I'm wrong on this.

TODO

Tests shouldn't run an excessive amount of iterations. one is sufficient to validate an api behavior. that's not to say that if an api supports args up to 20 iterations, a tests should be done for each of those instances (range of 1-19 iterations, and negative tests for 0 and 20 iterations).

querying random test data from supabase is a practice I want to continute, but to speed up testing test data should be shared where possible. I dont see any reason the results from the sql query can't be shared across a spec's whole test suite or even between test suites.

• refactor existing tests to only include minimally necessary iterations
• refactor existing tests to re-use test data
• refactor existing tests to only use psql-supplied test data. (hardcoded test data shouldn't be used)