3 ms·

I prefer integration testing over unit testing because each test case covers many more lines of code (since it also traverses dependencies). You can use mocks a

I prefer integration testing over unit testing because each test case covers many more lines of code (since it also traverses dependencies). You can use mocks and stubs to allow the test suite to reset/set the state of the system between each test case so integration tests don't have to be brittle, unreliable or require launching other services on the side. I find that it's a good architectural pattern if the main state stores in a software can be easily substituted with mocks or stubs; in my experience, this makes the software more reliable, easier to maintain and more testable.

rikroots 4y ago
This. I have nothing against unit testing; there's been times when a unit test (often written by someone else) has stopped me pushing some truly stupid code to production. But when I started developing my canvas library (for fun, not work) I decided early on that unit testing every line of code was not only sucking the joy from the work, but also too hard to cover all the edge cases of what I was trying to deliver: responsive, interactive, animated graphics, often controlled by user interaction with the canvas element. So instead I developed a big bunch of demos which try to cover the full functionality of the library, which I can visually check locally before pushing code changes to the repo[1]. The big drawback is I have to check all these tests/demos manually (across browsers and devices) before releasing a new version of the library into the wild. Automating that process is on my list of Things To Do - if anyone has suggestions/insights into current tooling/testing suites that could help me then I'm very willing to listen and learn! [1] - https://scrawl-v8.rikweb.org.uk/demonstrations https://scrawl-v8.rikweb.org.uk/demonstrations
- jongjong 4y ago
  I still use unit testing for modules which are particularly complex.

rikroots 4y ago

This. I have nothing against unit testing; there's been times when a unit test (often written by someone else) has stopped me pushing some truly stupid code to production. But when I started developing my canvas library (for fun, not work) I decided early on that unit testing every line of code was not only sucking the joy from the work, but also too hard to cover all the edge cases of what I was trying to deliver: responsive, interactive, animated graphics, often controlled by user interaction with the canvas element. So instead I developed a big bunch of demos which try to cover the full functionality of the library, which I can visually check locally before pushing code changes to the repo[1]. The big drawback is I have to check all these tests/demos manually (across browsers and devices) before releasing a new version of the library into the wild. Automating that process is on my list of Things To Do - if anyone has suggestions/insights into current tooling/testing suites that could help me then I'm very willing to listen and learn! [1] - https://scrawl-v8.rikweb.org.uk/demonstrations https://scrawl-v8.rikweb.org.uk/demonstrations

jongjong 4y ago
I still use unit testing for modules which are particularly complex.