[blog] testing flux applications

[fisherwebdev]

No description provided.

[glenjamin]

I'm not sure if this is a useful place to leave this comment, but i'll try it anyway:

Is there an advantage to extracting the registered callback from the mocked dispatcher over just not mocking the dispatcher?

There's a reasonable chunk of the blog post taken up explaining the gymnastics being done to extract the dispatcher callback, when (as I understand it), dontMock would be a bit more straightforward.

[fisherwebdev]

You could certainly write tests that way, and I have at times followed that route. There is nothing "wrong" with it per se, it simply adds another thing (theoretically, or who knows, maybe practically) to consider when things don't work as expected.

The ideal of unit tests is to test a single unit. Integration tests, on the other hand, test the interaction between multiple parts of a system. So what you are describing is moving toward an integration test, not a unit test.

Whether or not mocking the dispatcher matters in practice is a matter of debate, but in theory, at least, we can all see that we're no longer testing the store in isolation if we don't mock the dispatcher. In that case, there is always the outside chance that it's something outside the store that's to blame for failing tests -- you won't know exactly where to look to find the bug.

[fisherwebdev]

By the way, on this topic -- definitely check out that classic Martin Fowler essay that I recommended at the end of the post: Mocks Aren't Stubs -- Fowler might agree with the point you're making, but he has sympathy for both sides of the argument.

[glenjamin]

Thanks for the thoughtful response - I'd gotten into the habit of my current way of approaching mocking, so it's good to be reminded there's more than one valid way!

Another thing that occurred to me on re-reading is that there are no assertions on the 'change' event being emitted. Is this something you think would be worth including in store tests in general?