Unit tests which have working URLs

[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

[MattTennison]

Hmm, I suppose there's two approaches here:

1. Mock out network calls in our unit tests to return test data (making the URLs not really matter)
2. 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]

Haha a GIF speaks a thousand words 😂

I hadn't considered option 1... In the unit test I think it'd be pretty easy to switch out the URI with a fetch from the dataset, but I think it'd be more challenging for those calls which are side-effects, e.g. when a describer has model.read(localUri) it will try to hit the local URI and fail (actually we mostly hit the full URI like this rather than using a relative path)

A good starting point for option 2 would be to make the base URL configurable

Yeah this is a good starting point I think! We'll need that for deploying to a remote server anyway.. opened a new issue for it here: #23