4 ms·

As a physics PhD spending most of my time on writing code for numerical simulations, I generally agree that unit tests are a waste of time for most things. Unfo

As a physics PhD spending most of my time on writing code for numerical simulations, I generally agree that unit tests are a waste of time for most things. Unfortunately, most people nowadays seem to think you either fetishize unit test coverage percentages or don't care about code quality at all. In practice, at least for simulation code, functional, integration and regression tests are useful when employed judiciously. Most importantly, you verify your results using published benchmarks in the scientific literature or analytic results where possible. Obsessively covering every trivial bit of code with a unit test of its own has always struct me as rather a weird fad.

fsloth 9y ago
"Obsessively covering every trivial bit of code with a unit test of its own has always struct me as rather a weird fad." The advantage unit tests have over regression tests is that the time between the moment developer implemented a change and finding out they broke something is as small as possible. When tens of people work on the same codebase this saves enormous amount of effort. Fethisizing over some rule for it's sake is silly of course. My org would waste a lot of money and time without unit tests. Another feature unit tests provide: Think of the unit tests as a living documentation. Breaking something leaves a breadcrumb trail to the invariant which was sullied.
- keldaris 9y ago
  I'll happily grant the point that unit tests are, to a considerable extent, the price you pay for putting more developers in charge of the same parts of the codebase. In my line of work that's usually not a concern, but I can see merit in the idea for large teams. I also think that statement scales down in the sense that unit tests rarely make sense for code written and maintained by one or two people.
  - fsloth 9y ago
    "I also think that statement scales down in the sense that unit tests rarely make sense for code written and maintained by one or two people." I am maintaining several end user critical projects related to data transform and transport, mostly by myself. I have no idea how I could develop them as efficiently without unit tests to verify my changes don't brake some corner case as new features are added. The cadence for changes can be fairly low - I might return to some component after doing something else for six months, and I probably need to add some feature without breaking something in the process. Sure, we have integration testing and smoke testing, but the further a bug travels the release pipeline from the developer the more expensive it is to fix. This cost cascade is quite easy to visualize - the work of whomever caught the bug is stopped, and depending where they are located in the product ecosystem their stall can cause lots of work for other people. If they are a tester they need to file a report. If they are a customer, their work is interrupted, they contact local sales, who then contact global helpdesk, who then identify and log the bug. Much simpler and easier if there is a unit test to catch the bug in the first place. Now, there can be domain specific flavors to this. My domain is computational geometry and transport of 3D modeling data between domains. But in my domain anyone not securing their code with unit tests is wasting their employers money and setting their end users at risk by increasing the likelihood of bugs. There is lot of cargo cult nonsense in software engineering. Unit testing is not one of them. It saves time and effort by catching a range of bugs not caught by e.g. compiler for statically typed language and it secures the program logic for future changes.
jpindar 9y ago
Equating unit tests with 100% code coverage is a strawman. I don't think most people care about full coverage, and in some kinds of code it would be impossible.

fsloth 9y ago

"Obsessively covering every trivial bit of code with a unit test of its own has always struct me as rather a weird fad." The advantage unit tests have over regression tests is that the time between the moment developer implemented a change and finding out they broke something is as small as possible. When tens of people work on the same codebase this saves enormous amount of effort. Fethisizing over some rule for it's sake is silly of course. My org would waste a lot of money and time without unit tests. Another feature unit tests provide: Think of the unit tests as a living documentation. Breaking something leaves a breadcrumb trail to the invariant which was sullied.

keldaris 9y ago
I'll happily grant the point that unit tests are, to a considerable extent, the price you pay for putting more developers in charge of the same parts of the codebase. In my line of work that's usually not a concern, but I can see merit in the idea for large teams. I also think that statement scales down in the sense that unit tests rarely make sense for code written and maintained by one or two people.
- fsloth 9y ago
  "I also think that statement scales down in the sense that unit tests rarely make sense for code written and maintained by one or two people." I am maintaining several end user critical projects related to data transform and transport, mostly by myself. I have no idea how I could develop them as efficiently without unit tests to verify my changes don't brake some corner case as new features are added. The cadence for changes can be fairly low - I might return to some component after doing something else for six months, and I probably need to add some feature without breaking something in the process. Sure, we have integration testing and smoke testing, but the further a bug travels the release pipeline from the developer the more expensive it is to fix. This cost cascade is quite easy to visualize - the work of whomever caught the bug is stopped, and depending where they are located in the product ecosystem their stall can cause lots of work for other people. If they are a tester they need to file a report. If they are a customer, their work is interrupted, they contact local sales, who then contact global helpdesk, who then identify and log the bug. Much simpler and easier if there is a unit test to catch the bug in the first place. Now, there can be domain specific flavors to this. My domain is computational geometry and transport of 3D modeling data between domains. But in my domain anyone not securing their code with unit tests is wasting their employers money and setting their end users at risk by increasing the likelihood of bugs. There is lot of cargo cult nonsense in software engineering. Unit testing is not one of them. It saves time and effort by catching a range of bugs not caught by e.g. compiler for statically typed language and it secures the program logic for future changes.

jpindar 9y ago

Equating unit tests with 100% code coverage is a strawman. I don't think most people care about full coverage, and in some kinds of code it would be impossible.