This is a very good addition recognising the implicit module environment we're all most probably working in (leveraging tools like Webpack, etc.), thank you for sharing this!
This brings in a lot of unnecessary clutter that is needed to create singletons in OO programming languages with namespaces and classes.
This is a singleton in JavaScript (assuming global scope):
const ProcessManager = {
numProcess: 0,
increment() {
this.numProcess++
}
}
Now I'm not saying it cannot be done that way, but having this implementation is more true to the nature of JavaScript.
Start with an integration test (do an actual API request, expect it to return some data).
Start writing smaller unit tests for functions, that will be composed into the routine that gets the request -> serves the response. That way, you'll think about breaking things apart and will have small modules / functions to test.
Presto! You have a bunch of unit tests and one integration test, that pretty much covers the testing trophy paradigm. Oh, and if you'll write tests first, you're doing TDD now.
These specific character sequences are part of regular expression substitution flags (correct me if I'm wrong on the terms), so you can also use capture group references, which are arguably more useful in most replace scenarios, such as:
// results in <div>hello</div>
'<div></div>'.replace(/(<div>)(<\/div>)/, '$1hello$2')
// or you can make it more explicit, because the function
// receives result of RegExp.exec(String)
'<div></div>'.replace(/(<div>)(<\/div>)/, (match, g1, g2) => `${g1}hello${g2}`)