New article: making Sinon work with complex setups #2540
Conversation
Codecov ReportAll modified lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2540 +/- ##
=======================================
Coverage 95.95% 95.95%
=======================================
Files 40 40
Lines 1904 1904
=======================================
Hits 1827 1827
Misses 77 77
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| To better understand the example and get a good description of what seams are, we recommend that you read the [seams (all 3 web pages)][seams] excerpt from [Working Effectively with Legacy Code][legacy] before proceeding. | ||
| This guide targets the CommonJS module system, made popular by NodeJS. There are other module systems, but until recent years this was the de-facto module system and even when the actual EcmaScript Module standard arrived in 2015, transpilers and bundlers can still _output_ code as CJS modules. For instance, Typescript outputs CJS modules per default as of 2023, so it is still relevant, as your `import foo from './foo'` might still end up being transpiled into `const foo = require('./foo')` in the end. | ||
|
|
||
| <!-- TODO: input link to the other article on stubbing ESM --> |
There was a problem hiding this comment.
I should add that link now 😅
docs/_howto/typescript-swc.md
Outdated
|
|
||
| The important difference to note about the object `Other` is that the property `toBeMocked` is a simple writable _value_ in the case of `ts-node` and a non-configurable _getter_ in the case of SWC. It being a getter is not a problem for Sinon, as we have a multitude of options for replacing those, but if `configurable` is set to `false` Sinon cannot really do anything about it. | ||
|
|
||
| If we take a look at |
There was a problem hiding this comment.
Incomplete sentence 🤦♂️
| > [Working code][pure-di] | ||
|
|
||
| This technique works regardless of language, module systems, bundlers and tool chains, but requires slight modifications of the SUT to allow modifying it. You also do not get help from Sinon in automatically resetting state. | ||
|
|
There was a problem hiding this comment.
Could add a link to the ongoing PR I made to address this
|
|
||
| ## Use pure dependency injection | ||
|
|
||
| > [Working code][pure-di] |
There was a problem hiding this comment.
Include link to section on testing in Single Page Apps In Depth
https://singlepageappbook.com/maintainability3.html#testing-interactions-between-modules
|
Nice article! |
This is not being used, not being updated and is included in two other places
Included in /guides
Sprinkling some whitespace makes the article read a lot easier
In a few years, quibble will not be a newcomer anymore
fatso83
force-pushed
the
docs-how-to
branch
from
492a09e
to
bfc39fe
Compare
|
Thanks for the article @fatso83, just a comment. What if one does not want to use swc? and configure its jest in a way to export the configureable objects? |
|
See the two highlighted sections. This is not meant as a guide on SWC or Typescript, which was just chosen as a popular and slightly complicated example that could be used to show different techniques. It's a general guide on how you can analyse the situation and figure out how to work around it once you know what's going on. I don't know your particular case and what the issue is, but we're not really a support channel, use StackOverflow or ChatGPT for that. We are interested in improving docs to avoid confusion, of course, so any tips is worth mentioning. Wrt Jest I used it with Typescript and Sinon in a previous project. I remember that as working fairly well. Jest has control over the entire runtime, so it can do magic a library cannot 🪄 AFAIK we used the built-in jest.mock(...) for replacing dependencies. You can then choose to either create the stubs using Sinon or Jest. It's mostly a matter of preference. I don't know how to configure Jest to do what you propose, but I think you would need a plugin at least. Maybe even write it yourself. A newer approach of the old manual DI, is the "no extra tooling needed" approach that was just exposed with the new sandbox.replace.usingAccessor. That allows for tests that will work the same in Jest or Mocha or any other runner. You should check it out. I should of course update the article to mention that. |
Purpose
Wrote an article with-step-by-step instructions in how one can figure out what is preventing you from getting Sinon to work in most environments, and show three different approaches that all enable you to use Sinon in mocking dependencies.
This is basically an elaboration of what I wrote in #2528
Rendered as PDF: Case study: real world dependency stubbing.pdf
Testing in Jekyll:
cd docs; bundle install; npm run serve-docs