I found this to have many questionable claims for example:
> Ensure that all Logic classes can be constructed without providing any parameters (and without using a DI framework). In practice, this means that most objects instantiate their dependencies in their constructor by default, although they may also accept them as optional parameters.
When you do the latter, it kind of defeats the purpose of dependency injection and what you are testing won't be what you use in prod. And when you don't do this, you have to set up dependencies properly - at that point it's almost becomes an integration test. IMO the right thing here is to mock dependencies in unit tests so you can properly test the class in question.
Fundamentally, it seems like the author hasn't worked on or considered complex distributed systems where stuff like dependency management, sequencing (back and forth interactions), etc really matter - you can't test those properly in unit tests, you need integration tests.
Unit tests and integration tests complement each other, you can't reasonably test and update complex systems without both.
> Uses JavaScript, which is notoriously hard to test because of complex UI frameworks and difficult-to-mock APIs
It really depends. I’ve found testing JS/TS to range from “damn this is not worth automating” to “this is how it should be”.
Obviously UI frameworks may fall in the former category, but IME this is a place where JSX really shines: it’s an unopinionated DSL, perfectly fit to stub however you see fit. Much more complex is testing DOM and event loop behavior.
Server-side (non-presentational) JS/TS may be difficult to test, but that’s really more an accident of history than anything. It almost all depends on the Express API or something like it, and it’s damn near impossible to reason about at a unit level or as a statically analyzable system. But it doesn’t have to be that way, and I’ve developed complex systems without this problem, to the point unit tests provide enough confidence that few if any integration tests were of any value. Which in the article’s parlance means nearly all tests other than internal library code were testing pure logic functions or infrastructure functions. (I’m still sad I wasn’t able to open source this library code but a new implementation is on my side project list.)
> Set of patterns that refer to one another, providing mutual support
I first skimmed the article then re-read it, because I found this challenging as a reader trying to keep track of my cross-reference stack. It was better on a second pass, but I do think there’s an opportunity to inline some linked information at the expense of redundancy to minimize that, and to treat this format as more of a reference backing the article.
• Shows (almost) real-world examples to demonstrate the patterns
• Uses JavaScript, which is notoriously hard to test because of complex UI frameworks and difficult-to-mock APIs
• Set of patterns that refer to one another, providing mutual support
Would love to read more—any other resource along similar lines appreciated