5 ms·
It’s worth noting that using the fat arrow syntax for class functions make them exponentially harder to unit test because they do not exist on the Prototype of
by sorahn 8y ago
It’s worth noting that using the fat arrow syntax for class functions make them exponentially harder to unit test because they do not exist on the Prototype of the component, but are instead only initialized when the class is initialized.
If you are trying to unit test a function that calls another function in the same class you cannot mock the second one it if it is a fat arrow.
- dvlsg 8y agoI feel like testing things by replacing pieces of a prototype would be fairly fragile anyways. Is there a reason you couldn't use some form of composition to mock / abstract your dependencies instead?
- sorahn 8y agoGiven this super contrived example: https://gist.github.com/sorahn/2b287c2a97a12e318585e84d9a9e837e https://gist.github.com/sorahn/2b287c2a97a12e318585e84d9a9e8... If 'baz' was a fat arrow function, you would never be able to test bar in isolation. for example: Jest is set up so it's super easy to say `jest.spy(Foo.prototype, 'baz').mockReturnValue('whatever')`and test that bar is doing the right thing.
- Touche 8y agoMocking should only be used for extreme circumstances. This class is very easy to test without mocking. `bar` takes no arguments and has no external dependencies and therefore should always return the same result.
- sorahn 8y agoOK, you caught me, give bar an argument. (I'll edit the gist) Why should mocking only be used in 'extreme circumstances'? I want to test what bar does, and I don't care what baz does, and if someone breaks baz, my unit tests for bar shouldn't fail, because it is doing its job. I would mock it if it was calling some function in another module, so what's the difference if it's calling another function in the class?
- yorwba 8y agoMocking a component means that you now have two places where that component's behavior is specified and they can diverge. To prevent that, you'll need an integration test where the components interact directly. Just not using a mock is enough to get such an integration test. Then the value of the original, mocked unit test is questionable. It only provides additional information in the event that the mock differs from the actual component. If that's unintentional, then either the component is wrong (which should be caught by the tests for that component) or the mock is wrong. In either case, the mocked test provides little or negative value. Then the remaining case, where mocking is actually useful, is when the mock intentionally shows different behavior. Mocking a slow computation to return the result instantly. Deliberately failing, to test error-handling code. Simulating unlikely events in general. Those are good uses of mocking. TL;DR: Write more integration tests instead of unit tests with mocking.
- sorahn 8y ago> TL;DR: Write more integration tests instead of unit tests with mocking. Interesting. I will investigate what that looks like at work tomorrow. Thanks!
- jholman 8y agoI also think it's worth noting that fat arrow class methods is not a feature of JavaScript/ECMAScript, but rather a feature of Babel. It might make it into a future standard, but so might decorators (including autobinding decorators) or double-colon syntax for binding. None of these is currently legal vanilla JS.