[jeffmcmahan]

Everything in this article is correct except the conclusion that it's better not to write tests. Testing is an artform all its own. I find two tricks indispensable.

First I declare a "foo.src.js" file to hold a module's logic, and then a test file as "foo.js" and have the test file import the logic and then export whatever is to be public. Client code imports the test file and not the source file, so the tests sit in between the logic and the client code, as it were. No more balancing testability against encapsulation.

The second is indirection. I create a mockability decorator. Then have a function (I call it 'mock') which can be used to temporarily redefine any function declared mockable, and then switch back to the real thing when the current test is through. So I get:

    const readFile = mockable(fs.promises.readFile)

    ...

    mock(readFile)(async () => 'mock file contents')

Combining these approaches doesn't so much prevent rework on tests when code changes as it makes it much less trouble to implement tests for 98% of cases.

[LoSboccacc]

a missing link is that one specialized tester in a team every 5-8 devs makes devs a lot happier, makes test more robust and makes the whole squad more productive especially reducing regression over time by a lot, especially on fields where the code has to run on multiple platform and devs only ever use one.

it amazes me we're doing the opposite of the best practices by piling everything unto the mythical full stack dev, while the rest of the world moves toward specialization

this focus on forcing devs on writing tests and learning to test better is highly inefficient for all parties involved, both in term of output quality and time commitment.

and the first thing that gets cut when under time pressure is, in fact, testing. and a dedicated tester is resistant to that.

the real thing is.. almost nobody want to pay top money for a specialist so nobody wants to specialize in the profession.