5 ms·

I started believing in unit tests the day I finished my patch, ran the program and watched it work perfectly. I then grudgingly wrote a test, ran it and immedi

I started believing in unit tests the day I finished my patch, ran the program and watched it work perfectly. I then grudgingly wrote a test, ran it and immediately observed it fail. One of the test inputs was some garbage input and that exposed a poorly written error handling path. Humbling! I still hate writing them and it grates on my aesthetic sense to structure code with consideration to making it testable, but if we want to call ourselves engineers we need to hold ourselves to engineering standards. Bridge builders do not get to skip tests.

cfiggers 3y ago
> if we want to call ourselves engineers we need to hold ourselves to engineering standards. Bridge builders do not get to skip tests. Bravo. We need more of this mindset in the world, and also more collective will to encourage it in one another. YOU are the kind of engineer I want writing the code that goes in my Dad's pacemaker or the cruise control in my wife's car.
- m3kw9 3y ago
  If you have worked in places where safety is critical, you wouldn’t say something so shallow. In those places they place human verification above all else. They have a thick book where you do a full run and is double checked, they don’t f around with unit tests and say this is good to go
  - ska 3y ago
    I don't think anyone is saying unit tests and you are good to go are they? In any critical system work, there are multiple layers and you can't really skip any of them. It's also sort of meaningless to talk about such testing without requirements and spec to test against. Traceability is as much a part of it as any of the testing. By the time you get to the "thick book/full run" as you put it, there has typically been a metric crapload of testing done already.
  - Ancapistani 3y ago
    Human verification is very expensive, compared to unit tests. It costs money to pay that human to do it, time for them to test it, time to describe issues found, time to send it back for a fix. Unit tests - actually, all automated tests - are comparatively cheap. The developer can run them immediately. All code will have bugs. The "trick" to building a productive development pipeline is to catch as many of those bugs as possible as early as possible, and thereby reduce both the temporal and monetary cost of resolving them.
  - rcxdude 3y ago
    For all the testing and paperwork, the code in safety critical applications is still frequently awful and riddled with bugs, following such a process does not actually guarantee good software, it mostly just means you need a lot of paper pushers.
m3kw9 3y ago
You could have watch the program and observed the failure, why need to write a test to be “surprised” it failed
- corndoge 3y ago
  The program worked! As I wrote, the test tried a rare error condition and the handling for that was faulty. Updated the original to clarify. Hope that helps!
- therealdrag0 3y ago
  A huge benefit of tests is their regression protection against future changes, often by other engineers. You don’t get that from ad hoc manual execution.
  - nerdponx 3y ago
    This. I like tests because it's hard to know if I accidentally broke something other than the thing I'm working on. Even software of modest size is at a level of complexity beyond what a human can QA in a reasonable amount of time for every revision. If you're at the point of needing a checklist with even 3 items on it, you're past the point of needing tests.
- pfdietz 3y ago
  CPU cycles are so cheap these days that this is a gross waste of manpower. Even better than manually written unit tests are automatically generated property-based tests (which can be unit or integration tests). One can literally run millions of tests in a day this way, far, FAR more than could ever be manually verified. All because computation is so darned cheap now.
diarrhea 3y ago
Interesting take. I find structuring code to be testable to make the code much clearer: mainly, by making dependencies explicit via dependency injection. I do that even if I don’t end up testing the code.
- throwaway2037 3y ago
  I have an identical experience. What really made me understand dependency injection (in Java) was being forced to write 100% code coverage unit tests. To be clear: 100% code coverage was absolutely overkill for my domain, but it was a lesson about how to structure your code for dependency injection.
icedchai 3y ago
I work on a team with 75% of the developers don't write any tests. You never know what you're going to run into. Did I cause a new bug, or did I discover an old one? It's embarrassing when you discover completely non-working code paths. I'm not even looking for a particularly high level of test coverage, just a basic "I wrote an API, here's a test (integration, unit, doesn't matter) for the happy path"-level of coverage would be great. On the opposite end, I worked at places that wanted unit tests for every new function, even if it was something simple (like a getter or setter) used elsewhere. That's also terrible.

cfiggers 3y ago

> if we want to call ourselves engineers we need to hold ourselves to engineering standards. Bridge builders do not get to skip tests. Bravo. We need more of this mindset in the world, and also more collective will to encourage it in one another. YOU are the kind of engineer I want writing the code that goes in my Dad's pacemaker or the cruise control in my wife's car.

m3kw9 3y ago
If you have worked in places where safety is critical, you wouldn’t say something so shallow. In those places they place human verification above all else. They have a thick book where you do a full run and is double checked, they don’t f around with unit tests and say this is good to go
- ska 3y ago
  I don't think anyone is saying unit tests and you are good to go are they? In any critical system work, there are multiple layers and you can't really skip any of them. It's also sort of meaningless to talk about such testing without requirements and spec to test against. Traceability is as much a part of it as any of the testing. By the time you get to the "thick book/full run" as you put it, there has typically been a metric crapload of testing done already.
- Ancapistani 3y ago
  Human verification is very expensive, compared to unit tests. It costs money to pay that human to do it, time for them to test it, time to describe issues found, time to send it back for a fix. Unit tests - actually, all automated tests - are comparatively cheap. The developer can run them immediately. All code will have bugs. The "trick" to building a productive development pipeline is to catch as many of those bugs as possible as early as possible, and thereby reduce both the temporal and monetary cost of resolving them.
- rcxdude 3y ago
  For all the testing and paperwork, the code in safety critical applications is still frequently awful and riddled with bugs, following such a process does not actually guarantee good software, it mostly just means you need a lot of paper pushers.

m3kw9 3y ago

You could have watch the program and observed the failure, why need to write a test to be “surprised” it failed

corndoge 3y ago
The program worked! As I wrote, the test tried a rare error condition and the handling for that was faulty. Updated the original to clarify. Hope that helps!
therealdrag0 3y ago
A huge benefit of tests is their regression protection against future changes, often by other engineers. You don’t get that from ad hoc manual execution.
- nerdponx 3y ago
  This. I like tests because it's hard to know if I accidentally broke something other than the thing I'm working on. Even software of modest size is at a level of complexity beyond what a human can QA in a reasonable amount of time for every revision. If you're at the point of needing a checklist with even 3 items on it, you're past the point of needing tests.
pfdietz 3y ago
CPU cycles are so cheap these days that this is a gross waste of manpower. Even better than manually written unit tests are automatically generated property-based tests (which can be unit or integration tests). One can literally run millions of tests in a day this way, far, FAR more than could ever be manually verified. All because computation is so darned cheap now.

diarrhea 3y ago

Interesting take. I find structuring code to be testable to make the code much clearer: mainly, by making dependencies explicit via dependency injection. I do that even if I don’t end up testing the code.

throwaway2037 3y ago
I have an identical experience. What really made me understand dependency injection (in Java) was being forced to write 100% code coverage unit tests. To be clear: 100% code coverage was absolutely overkill for my domain, but it was a lesson about how to structure your code for dependency injection.

icedchai 3y ago

I work on a team with 75% of the developers don't write any tests. You never know what you're going to run into. Did I cause a new bug, or did I discover an old one? It's embarrassing when you discover completely non-working code paths. I'm not even looking for a particularly high level of test coverage, just a basic "I wrote an API, here's a test (integration, unit, doesn't matter) for the happy path"-level of coverage would be great. On the opposite end, I worked at places that wanted unit tests for every new function, even if it was something simple (like a getter or setter) used elsewhere. That's also terrible.