Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test Usage example #17

Open
Bwvolleyball opened this issue Jul 26, 2023 · 2 comments
Open

Test Usage example #17

Bwvolleyball opened this issue Jul 26, 2023 · 2 comments

Comments

@Bwvolleyball
Copy link

The docs mention that the createFetcherStore / createMutatorStore global config should help with test setup and mocking of data, but, there's no practical example of what this looks like.

Do you happen to have a small example that shows how to do this in a test?

@dkzlv
Copy link
Member

dkzlv commented Jul 28, 2023

@Bwvolleyball Hi there!

Honest answer: we do have examples, but they are temporary/0.1 version/we're not really sure if that's the best way forward.

It's very much related to #8 (initial states and SSR), and the real answer is that current way of doing tests/SSR/stories is painful.
The broad idea is this:

  1. nanoquery returns a third argument, which has a function (not part of the stable API) called __unsafeOverruleSettings
  2. essentially, this function overrules everything you provided for all fetcher stores, including the fetcher function itself
  3. so, basic guidance is this:
    1. call this function, provide it with a mocked version of the fetcher like this: __unsafeOverruleSettings({fetcher: jest.fn().mockImplementation(() => ...)})
    2. reset it after each test like this: __unsafeOverruleSettings()

Another way of doing the same is to use MSW, which is a much more robust and thoughtful way of testing network-related stuff, but that's out of the scope for nanoquery doc.


I'll share our vision for testing in near future.

We have a WIP PR for a new entity in the core of nanostores called Context. Context is essentially a place where all state for all atoms is stored. Once we land it in the main nanostores repo (I suspect it'll happen in August), I'll adapt nanoquery to this concept, and it'll simplify things a lot.

Using this new concept you'll be able to explicitly set a value for any atom by its reference for a certain isolated context (e.g., a single test unit!). I'll probably move fetcher functions inside atoms, which will give you a granular tool to change a fetcher function for a single fetcher/mutator store for a single test. That should probably be the better way that won't be nanoquery specific at all and will be the new way to test everything nanostores-related.

In the meantime—yeah, gotta use what we have.

@Bwvolleyball
Copy link
Author

Thank you, this is incredibly helpful, and I really appreciate the tips and tools you are able to document, and I'm excited to see the vision!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants