3 ms·
> I stopped thinking about "unit testing" and just started thinking "when I write some code, I should write some other code that runs the code automatically".
by jjice 3y ago
> I stopped thinking about "unit testing" and just started thinking "when I write some code, I should write some other code that runs the code automatically".
I like that perspective. Personally, the difference of "unit" vs "integration" testing from an organization/thinking perspective for me is what has to be available when it runs. We currently have .test.ts and .int.test.ts files in our code base. The former gets to run really fast without any dependencies, and the latter takes longer to run, but has full access to DBs and Redis. That separation just helps split it up for CI.
Thinking about it, you can probably combine them and just require everything is always available, but I've found that the distinction has helped how I think about writing pure functions and allows me to iterate on them with tests easily.
- dools 3y agoYeah I sometimes write tests that are separate from external dependencies still, I think the freedom I gained through this attitude is that I don’t stress too much about it, especially in the early stages. This gives me “good enough” coverage most of the time without the sorts of extreme bending over backwards to mock out every little dependency that a purist unit testing approach would entail. As a side note I really liked using Lettuce when I was working with Django not so much because of the whole “BDD” thing which was lost on me but because of the way they did database fixtures. I wrote a little automated test runner in PHP that uses the same approach, and later wrote a little test runner in node with the same name (but never implemented database testing in it because I’m not masochistic enough to use asynchronous code to access a database): https://github.com/iaindooley/murphy https://github.com/iaindooley/murphy