MattTennison
commented
3 years ago Hmm, I suppose there's two approaches here:
- Mock out network calls in our unit tests to return test data (making the URLs not really matter)
- Make real network calls, against a mock server - these would technically be integration tests rather than unit tests, as they're calling other services.
What you're describing sounds like 2. Option 2 is good, I tend to find integration tests for valuable than unit tests, they're more focused on the behaviour we care about and involve less mocking. This is good as we're still changing our API structure fairly often, and if we write loads of mocks at the unit level, they'll need to be updated when we make changes. We can still use JUnit as well, it'd just be calling application code at a higher level). Also: https://twitter.com/erinfranmc/status/1148986961207730176
Option 1 would give us faster test runs, as instead of testing the full stack we'd be testing lots of 'given input return output'.
A good starting point for option 2 would be to make the base URL configurable - so whilst we might always want to reference /mud/world/#test-resource we want to be able to choose the actual server we're using. I tend to use environment variables for that, so we can compile once and leave it up to whoever is running the image to set the URL.
calummackervoy
It's not possible to use test data in our unit tests which blocks us from testing anything which pulls from a data source
They run on a test server using Grizzly, but we need to expose that on a port, and then write the tests to use that port in the test data URLs (e.g.
http://localhost:8080/mud/world/#test-resource), then we can write unit tests for features with reference and access test datasets@MattTennison do you have experience with this in JUnit ? I haven't researched it properly yet