3 ms·

This is why I'm neutral on the value of unit tests. Sometimes they are helpful, other times less so. I am always in favor of tests around the boundaries betwee

by lukev 3y ago

This is why I'm neutral on the value of unit tests. Sometimes they are helpful, other times less so. I am always in favor of tests around the boundaries between system components (regardless of what you call them; integration tests, API tests, etc.) The more robust the better. If I'm working on a system with robust (ideally generative) integration tests covering the interface of a component, I feel I have near-complete freedom to rewrite any aspect of the component I want with high confidence.

adonovan 3y ago
Unit tests are good when there are clear and durable units, but what many people seem to mean by a unit test is one that exercises the internal functions of a package, or the API of an internal package that evolves as fast as your product. Stable interfaces that the user cares about (e.g. CLI, public API, RPCs) make for the highest-value tests.
nomel 3y ago
> ideally generative How have you seen this done well? In my experience, this usually ends up being some hello-world type simplicity that doesn't really represent the real world use corner cases.
- lukev 3y ago
  I have, on multiple occasions. Unfortunately mostly on contracting gigs so I can't cite specifics but I've worked on a major ecommerce platform's api, and two separate databases using this approach. For public examples, I'd point you to (e.g.) Jepsen. I'm not going to deny it requires a pretty high level of time/money to implement. But done well it's super powerful.
randomdata 3y ago
> I am always in favor of tests around the boundaries between system components (regardless of what you call them; integration tests, API tests, etc.) Funnily enough, "unit tests" is what this was called originally. The boundary is what "unit" referred to. In my experience, these days most people just call them "tests". That they happen at the boundary is implied as by this point it is generally agreed upon that testing anything else is a waste of time at best and sometimes even detrimental. Which is why nobody in fake internet argument land can settle on what "unit", "integration", etc. mean in the modern age. There is nothing related to testing in need of additional qualification to communicate to other developers what isn't already communicated with "tests" alone.

by lukev 3y ago

adonovan 3y ago

Unit tests are good when there are clear and durable units, but what many people seem to mean by a unit test is one that exercises the internal functions of a package, or the API of an internal package that evolves as fast as your product. Stable interfaces that the user cares about (e.g. CLI, public API, RPCs) make for the highest-value tests.

nomel 3y ago

> ideally generative How have you seen this done well? In my experience, this usually ends up being some hello-world type simplicity that doesn't really represent the real world use corner cases.

lukev 3y ago
I have, on multiple occasions. Unfortunately mostly on contracting gigs so I can't cite specifics but I've worked on a major ecommerce platform's api, and two separate databases using this approach. For public examples, I'd point you to (e.g.) Jepsen. I'm not going to deny it requires a pretty high level of time/money to implement. But done well it's super powerful.

randomdata 3y ago

> I am always in favor of tests around the boundaries between system components (regardless of what you call them; integration tests, API tests, etc.) Funnily enough, "unit tests" is what this was called originally. The boundary is what "unit" referred to. In my experience, these days most people just call them "tests". That they happen at the boundary is implied as by this point it is generally agreed upon that testing anything else is a waste of time at best and sometimes even detrimental. Which is why nobody in fake internet argument land can settle on what "unit", "integration", etc. mean in the modern age. There is nothing related to testing in need of additional qualification to communicate to other developers what isn't already communicated with "tests" alone.