That seems pretty absolutist. Tested code is only as good as the tests themselves. I'd take readable, reliable code which covers all the corner cases over tested code that doesn't actually work reliably any day.

Of course, tests can help you achieve this kind of high quality code, and good tests have other benefits like helping you to prevent regressions when modifying the code, but you can still have high quality code without them and low quality code with them.

in my experience, taken from projects I worked on with and without tests, even bad tests are better than no tests at all.

No tests usually good indicators that there will be a lot of repeated and overcomplicated code. Having a solid test coverage allows you to change/extract functions at any point when you see something is getting outta shape. With no tests, however, it's much easier and less scary to add rather than change.

People often make a point that writing tests takes time, but I'm pretty sure it slows you down in the beginning of work and speeds you up quite a bit when you amount some volume, and further you go, more you benefit from having a decent coverage. Also, oftentimes, especially on the server side, it's just easier to implement/verify with automated test from the start rather than by hand.

None of it is related to the OP codebase, just thoughts in the abstract.

> People often make a point that writing tests takes time, but I'm pretty sure it slows you down in the beginning of work and speeds you up quite a bit when you amount some volume, and further you go, more you benefit from having a decent coverage.

I certainly hope that quality testing is more than just your preference or even a good practice: it's now a central part of software development. At this point, we know enough about the benefits of good testing to say that it's practically malpractice to not have them. Good tests may not be a strong enough signal to conclude that a project is good quality, but lack of tests is a clear sign that a project is low quality.

I tend to think about tests as insurance. Without them, you're flying blind.

let me guess - the people in those circles work for either already-profitable companies or companies flush with venture capital, rather than a company trying to get off the ground before it runs out of money?

I have worked for either established and startup companies (admittedly with varying success). I think it has more to do with the composition of the team. As engineers there are a lot of different experiences we can bring to the table, but some of us have had the transformative experience of being on projects where the testing was right, in how to do and the amount, and we have seen how it helps us on a daily basis to move faster and be humbled by the bugs that we'd otherwise have released, or that we'd otherwise would've had to troubleshoot on a remote system rather than fixing them minutes after creating them. I'm now making it a point to expose my team members to the same awesome experience. But I also understand that, as you're building a startup team, and there are many things you have to get right, this may be a skill you would go without.

Also, I'm not advocating 99+% test coverage for new (startup) projects, but one could start with some tests selectively for core functionality or the most complex parts, and already enjoy a great overall benefit.

What about the myriad of try catch console.log. With the statement in the readme "Database & file-based logging" unless they are overriding console, then I don't even know what they mean.

https://github.com/Viveckh/Veniqa/search?q=console.log&unsco...