It depends entirely on the project. For most (but not all) software projects, writing tests before you write code is wrong. For many (but not all) API-driven

It depends entirely on the project. For most (but not all) software projects, writing tests before you write code is wrong. For many (but not all) API-driven projects, I will write tests alongside my code. So if I would write a few dummy lines of code at the bottom of a file to confirm something is working, I'll write that up as a test instead. In order for that process to work, writing tests needs to be extremely easy -- you need to be able to add a test anywhere without thinking much about it or wasting time pre-organizing everything. On that note, shameless self-plug for Distilled (https://distilledjs.com https://distilledjs.com), a testing library I wrote that I use in all of my projects, and that I like a lot. The reason Distilled prioritizes flexibility is that I strongly believe there is no single, right way to do testing that can be applied to every project. - For Distilled, I do TDD development where I write tests before code. This is because Distilled has a rigid API and behaviors, and because I use my tests as documentation. Distilled aims to have 100% coverage: https://gitlab.com/distilled/distilled/blob/stable/src/tests/distilled/overview.js https://gitlab.com/distilled/distilled/blob/stable/src/tests... - For Serverboy, I only do integration tests based on test ROMs and comparing screenshots. Those screenshots get written out to my README and show the current emulator compatibility status. With Serverboy, I only care about the final accuracy of the emulator: https://gitlab.com/piglet-plays/serverboy.js/blob/master/tests/runner.js https://gitlab.com/piglet-plays/serverboy.js/blob/master/tes... - For projects like Loop Thesis (https://loop-thesis.com https://loop-thesis.com), I do a combination of unit tests and integration tests. I don't aim for 100% code coverage, and I think of my tests as a form of technical debt. For Loop Thesis I'm also adding performance tests though that let me know when the game is getting more or less efficient. - And with exercises or experiments, I add tests haphazardly on the fly alongside my implementation code, putting very little thought into organization: https://gitlab.com/danShumway/javascript-exercises/blob/master/eventor.js https://gitlab.com/danShumway/javascript-exercises/blob/mast... So every project has slightly different requirements and goals, and those goals drive my testing practices, not the other way around.