2

I'm writing unit tests for several Flux stores and encountered a small annoyance.

My stores are generally built like this:

storeObj = {
...
}

_secretsetterfunction = function (){}

module.exports storeObj

As you can see, since the setter function is outside of the store object - it's not directly accessible.

This presents a problem as the only way to test / manipulate the store data would be to go through the Action -> Dispatcher -> event listener (the Action can technically be cut out) which isn't something I would like to go through when unit testing a store.

The alternative is to actually put the setter methods on the store object - but this isn't something I'd really wish to do.

Any thoughts?

Aliaksandr Sushkevich
  • 11,550
  • 7
  • 37
  • 44
Guy Nesher
  • 1,385
  • 2
  • 14
  • 26

3 Answers3

4

I had this problem too, using Jasmine.

I wrote a blog post & example repo about how to get a reference to those private inner functions when you're not using Jest: http://bensmithett.com/testing-flux-stores-without-jest/

TL;DR - use rewire

Ben
  • 669
  • 1
  • 9
  • 20
2

Actions are effectively the public api of a store. You only need to verify the effects of actions to fully test your stores.

Brigand
  • 84,529
  • 20
  • 165
  • 173
  • I get that, and it does obviously work. But it can quickly become rather complicated, especially with the waitFor() command. – Guy Nesher Sep 21 '14 at 07:53
  • Not really, it's actually very simple. You set all of your tests to have a timeout, invoke an action, and you just wait for a change event on the store and validate the payload. There's no simpler way to do it. I do recommend mocha over jasmine... it has better support for this kind of thing afaik. – Brigand Sep 21 '14 at 08:05
  • I don't think dependencies between React stores are such a good idea. Using principles of CQRS/EventSourcing could help testability and scale better on large teams. See also http://stackoverflow.com/a/25806145/82609 – Sebastien Lorber Sep 22 '14 at 12:52
  • @SebastienLorber That's quite interesting, but probably going to far for our needs at the moment. – Guy Nesher Sep 25 '14 at 17:51
  • @FakeRainBrigand agree and that's what we are doing at the moment, still it feels like I'm doing more than a bit of extra work to test these - but I guess this is the best solution atm – Guy Nesher Sep 25 '14 at 17:52
0

So The flux team just addressed this in a blog post, though they are using their own variant called Jest. Still worth a read:

http://facebook.github.io/react/blog/2014/09/24/testing-flux-applications.html?utm_source=javascriptweekly&utm_medium=email

Guy Nesher
  • 1,385
  • 2
  • 14
  • 26