You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sinon library allows to mock JS objects. I see a lot of tests misusing it by mocking internals and relying on timing and execution order of internals. Such tests hard to maintain since they don't allow to change implementations easily. Instead of developers should rely on public APIs and don't make assumptions about internal flow. The issue with Sinon that it provides capabilities to mock such things easily.
I suggest we remove it and use plain JS for object mocking, i.e. <MyService>{}. It will make hard to mock internal control flow and discourage it. Plus we will reduce our dep tree and force to review test for such misusage.
The text was updated successfully, but these errors were encountered:
akosyakov
added
quality
issues related to code and application quality
proposal
feature proposals (potential future features)
test
issues related to unit and api tests
labels
Jun 12, 2019
It was pointed out at the dev meeting that we should define what is good test and look at it during PR review. Using sinon itself is not the reason for unstable tests.
Sinon library allows to mock JS objects. I see a lot of tests misusing it by mocking internals and relying on timing and execution order of internals. Such tests hard to maintain since they don't allow to change implementations easily. Instead of developers should rely on public APIs and don't make assumptions about internal flow. The issue with Sinon that it provides capabilities to mock such things easily.
I suggest we remove it and use plain JS for object mocking, i.e.
<MyService>{}
. It will make hard to mock internal control flow and discourage it. Plus we will reduce our dep tree and force to review test for such misusage.The text was updated successfully, but these errors were encountered: