5 ms·

Agree with everything except for unit tests, they're something of a cargo-cult fad. Any of my developers caught wasting their time on these would get a stern ta

Agree with everything except for unit tests, they're something of a cargo-cult fad. Any of my developers caught wasting their time on these would get a stern talking to.

fsloth 9y ago
You are kidding, right?
Boothroid 9y ago
Interesting - so how else do you test?
- dasmoth 9y ago
  End-to-end tests comparing output to hand-computed results on small examples (or perhaps the output of an earlier, simpler, prototype)? (For predictive models) evaluate the output on a test set? Depending on what you're trying to do, the contents of the black box may not matter so very much if the results on an agreed test set are good (...and you're confident it's independent from any training data...) Manual eyeballing and sanity-checking of output? (in my experience important however many layers of automated testing you're using, and undervalued by people who focus on software as an engineering process more than an art-form). ...and, circumstantially, probably a bunch of others. I don't think this is a field where making lots of rules is especially helpful (except, perhaps, the "always eyeball" one...)
  - Boothroid 9y ago
    Thanks, useful. I never seem to be allocated enough time to write tests and always worry as a result, since use of automated tests seem to be close to dogma for many. Along with agile it seems to be one of those things that people cling on to for security, appropriateness or otherwise notwithstanding.
b2811 9y ago
You must have a superhuman team. The only languages I could even remotely imagine to get by without tests are Haskell/ML. Even then, logic mistakes can and do still happen.
slackingoff2017 9y ago
I test API's and code I expect to reuse a lot but I agree on CRUD type stuff. If the code is being used in one place and bugs aren't all that consequential its a huge waste of time to test everything. I've found that unit tests are less important when you have good CI and your codebase isn't shit. On high quality code it takes so little time to fix bugs and redeploy that unit testing is a hard sell.
jimhefferon 9y ago
> Any of my developers caught wasting their time on these would get a stern talking to. Assuming this is serious, FWIW I'm a STEM PhD and I find that even in the smallest scripts, even just web-scraping stuff, if I don't write unit tests then I get it wrong and later discover I need to do it all again. Or worse, I figure out later, after I've built lots of code over this, that there is an error and the subsequent code all needs to be redone. In short, I find unit tests to be a big time and effort saver. And I get the right answer, for a change. :-)
keldaris 9y ago
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.
chris_wot 9y ago
Really? We use unit tests extensively in LibreOffice and its saved many bugs and man hours.
pps43 9y ago
Some unit tests are redundant and only waste time. Others are very useful. Do not write unit tests just because the methodology requires it. Write unit tests when the unit needs to be tested. Typical examples: * Smoke tests (does this code work at all?) * Tests for known edge conditions * Tests for known bugs (to catch regressions)

Agree with everything except for unit tests, they're something of a cargo-cult fad. Any of my developers caught wasting their time on these would get a stern talking to.

fsloth 9y ago

You are kidding, right?

Boothroid 9y ago

Interesting - so how else do you test?

dasmoth 9y ago
End-to-end tests comparing output to hand-computed results on small examples (or perhaps the output of an earlier, simpler, prototype)? (For predictive models) evaluate the output on a test set? Depending on what you're trying to do, the contents of the black box may not matter so very much if the results on an agreed test set are good (...and you're confident it's independent from any training data...) Manual eyeballing and sanity-checking of output? (in my experience important however many layers of automated testing you're using, and undervalued by people who focus on software as an engineering process more than an art-form). ...and, circumstantially, probably a bunch of others. I don't think this is a field where making lots of rules is especially helpful (except, perhaps, the "always eyeball" one...)
- Boothroid 9y ago
  Thanks, useful. I never seem to be allocated enough time to write tests and always worry as a result, since use of automated tests seem to be close to dogma for many. Along with agile it seems to be one of those things that people cling on to for security, appropriateness or otherwise notwithstanding.

b2811 9y ago

You must have a superhuman team. The only languages I could even remotely imagine to get by without tests are Haskell/ML. Even then, logic mistakes can and do still happen.

slackingoff2017 9y ago

I test API's and code I expect to reuse a lot but I agree on CRUD type stuff. If the code is being used in one place and bugs aren't all that consequential its a huge waste of time to test everything. I've found that unit tests are less important when you have good CI and your codebase isn't shit. On high quality code it takes so little time to fix bugs and redeploy that unit testing is a hard sell.

jimhefferon 9y ago

> Any of my developers caught wasting their time on these would get a stern talking to. Assuming this is serious, FWIW I'm a STEM PhD and I find that even in the smallest scripts, even just web-scraping stuff, if I don't write unit tests then I get it wrong and later discover I need to do it all again. Or worse, I figure out later, after I've built lots of code over this, that there is an error and the subsequent code all needs to be redone. In short, I find unit tests to be a big time and effort saver. And I get the right answer, for a change. :-)

keldaris 9y ago

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.

chris_wot 9y ago

Really? We use unit tests extensively in LibreOffice and its saved many bugs and man hours.

pps43 9y ago

Some unit tests are redundant and only waste time. Others are very useful. Do not write unit tests just because the methodology requires it. Write unit tests when the unit needs to be tested. Typical examples: * Smoke tests (does this code work at all?) * Tests for known edge conditions * Tests for known bugs (to catch regressions)