Skip to content
This repository has been archived by the owner on Mar 21, 2024. It is now read-only.

[RFC] Utilize Mock Server Worker for tests #90

Closed
david-chalk opened this issue Feb 20, 2024 · 5 comments
Closed

[RFC] Utilize Mock Server Worker for tests #90

david-chalk opened this issue Feb 20, 2024 · 5 comments
Assignees
Labels
enhancement New feature or request wontfix This will not be worked on

Comments

@david-chalk
Copy link
Collaborator

david-chalk commented Feb 20, 2024

NOTE: this issue tracks the discussion around the decision to even do this. This is not the implementation issue.

Situation

The FusionAuth React SDK currently extensively uses function mocking in order to test functions that access the network.

Challenge

While this ensures that a function by a particular name is called, it isn't a very robust way to check that a function does what it's supposed to do.

Question

How can we test functions that access the network in a more robust way that gives us more confidence in the results of our tests?

Answer

Let's use Mock Service Worker (MSW). MSW is the industry standard API mocking library that allows you to write client-agnostic mocks and reuse them across any frameworks, tools, and environments. It's well supported and has plenty of resources and documention.

Basically, we can utilize it to setup Service Workers that intercept network requests and respond with what we want to test. I.e. a function that accesses GET /some-endpoint won't need to be mocked. It will make it's request normally and the Service Workers will intercept the call and respond accordingly.

We're able to easily test multiple response types as well, so we can make sure any network failures are handled in an appropriate way as well.

This will let the code run that should run and the surface area of our tests will be increased and so will the accuracy of our tests.

MSW is also framework agnostic which means we could reuse the work we do for the other FusionAuth SDKs, increasing our confidence in those tests as well.

What's the lift? 💪

The FusionAuth React SDK doesn't hit very many endpoints (about 6), so even accounting for variations, we're not looking at too much setup time.

After setup, we just need to update the tests to remove the mocked calls. This also won't be very time consuming as there aren't many functions to worry about.

Estimate: 1 developer 1 day

@david-chalk david-chalk self-assigned this Feb 20, 2024
@david-chalk
Copy link
Collaborator Author

Requesting comments and thoughts from @mooreds.

@david-chalk david-chalk added the enhancement New feature or request label Feb 20, 2024
@michaelyons
Copy link
Collaborator

Requesting comments and thoughts from @lyleschemmerling

@lyleschemmerling
Copy link

I don't think is a bad idea, but as I just commented on #89 I do think we should be using the sdk example repo as the primary limtus for the functionality of the sdk. This will ensure that it does work with FusionAuth the way that we intend, and we also expect our customer we use these as well as a guide for setting up their own applications. Extra mocking in-repo would be nice as a bonus but I don't think is required

@david-chalk
Copy link
Collaborator Author

@lyleschemmerling Testing the SDKs in the example and quickstart repos is a great thing to do but that doesn't take away the benefit of having more robust tests within the project itself. We can't easily incorporate that style of testing in CI/CD processes in GitHub during releases - we can setup up some E2E testing like that but it's more complicated than setting up MSW.

I'm fine marking this as a "maybe later" thing though if we don't see a big benefit for right now. 👍

@lyleschemmerling
Copy link

let's keep this as "maybe later"

@david-chalk david-chalk added the wontfix This will not be worked on label Mar 1, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

4 participants