4 ms·

Being honest most companies I worked, unit tests have no use at all. They are just writen because someone determined some arbitraty percentage of code that need

Being honest most companies I worked, unit tests have no use at all. They are just writen because someone determined some arbitraty percentage of code that needs to be covered, and because it takes as much time to write the tests as to write the code, people just write useless tests that test absolutaly nothing usefull, and are worth nothing. And this is not small companies we are talking about. They are banks, big educational institutes, etc. In the end the only thing most managers care is that the litle label in the pipeline dashboard that indicates the test percentage stais green.

videogreg93 4y ago
Thank you! I feel like all of this Unit test stuff is just a case of Emperor's New Cloths: everyone writes tests, no one knows why but won't admit it. I've never never ever experienced in my life a time where a major problem was automatically found by some unit tests before it got pushed to production.
- UK-AL 4y ago
  I have. A lot.
  - cwilby 4y ago
    Our team too, time saved is fairly quantifiable.
    - disgruntledphd2 4y ago
      I mean, you probably need automated CI before this becomes likely as otherwise people just forget to run the tests...
      - nonethewiser 4y ago
        You absolutely need that.
        cwilby 4y ago
        Yes, test frequently and automatically.
- matthewfcarlson 4y ago
  This is sort of why I wrote the article. Professionally, I’ve seen tests just cause tons of noise and offer little benefit. So I tried applying it to a personal project on a whim and found some unexpected benefits
- jerf 4y ago
  "I've never never ever experienced in my life a time where a major problem was automatically found by some unit tests before it got pushed to production." Then you, or somebody near you, is doing it very wrong. I do not mean this as a moral judgment, I mean it as an engineering process diagnostic feedback. I literally can't count the number of times it has popped up a bug that I wouldn't have expected because of some change. It is that very characteristic that makes me love them so much. No matter how carefully you code you can never get away from the problem of a small change over there causing a breaking over here because of something you couldn't even have anticipated, but you don't have to wait until some large-scale QA process or even production deployment to find out; you can find out 15 seconds later, and then fix it, or realize your new change is fundamentally untenable, or any number of things. I'd say "I don't know how people develop without these things", except I do; the code bases are treated like quick-set concrete and nothing can be changed once laid down. What a stultifying way to code. I would hate to work at a job like that.
  - dwaite 4y ago
    > Then you, or somebody near you, is doing it very wrong. I do not mean this as a moral judgment, I mean it as an engineering process diagnostic feedback. IMHO thats the biggest problem with TDD. People often think of TDD as a set of requirements that all push for some set of benefits. But it is really a development methodology where you as a developer heavily utilize tests to drive the development process itself. It is a mindset, not a checklist. Perhaps easiest to explain (with an inaccurate comparison) as - it is like REPL-driven development but with persistent and sharable artifacts. Behavioral driven development is IMHO stronger in this regards, because people tend to understand how the additional artifacts (beyond what you might see with a requirements list or use case document) are part of a methodology. People can better separate the methodology from the benefits/outcome.
  - major505 4y ago
    Here is the thing: Most managers want you to implement the test and the code in the same time It would take to write only the code. The thing is, in the end most devs do shit tests becase theres no time allocated to that, and the test end up being just a number that needs to be met so the code could run to the dev ops engine and generte a new version of the software.
- nonethewiser 4y ago
  I think it can be taken too far but why not have some unit tests? They are the easiest kind of test to write and the fastest to run. Also, you dont see it because those bugs were fixed before production.
- spiddy 4y ago
  That's because by definition it is not going to be "major" problem since the unit test acted as gateway before it got pushed to production, instead you'll probably be 'meh' and fix it once the unit test fails. This reminds me the saying of a manager arguing why do we need so many SREs since the system is working fine.
- dwaite 4y ago
  Test driven development on one project would often save me weeks per bug fix. This was because it maintained an environment where I could replicate portions of the business logic (as assembled modules) outside a production environment. This made it much easier to do analysis/fuzzing of one component of the system, vs trying to replicate and do post-mortem crash analysis on the entire deployed system. But I clarify this is TDD, not unit tests. A development methodology where unit tests are wedged in after the fact do not promote the sort of modular programming needed to be able to do this.
donatj 4y ago
> people just write useless tests that test absolutaly nothing usefull, and are worth nothing. Oh man, those are my favorite. They're super difficult to critique in code review. "This test doesn't really test anything" isn't very helpful but writing a proper "do this" is often more work than writing a proper test yourself.
- nerdponx 4y ago
  Is that not helpful? It's definitely helpful. "This test doesn't do anything", then reject & request changes, "add substantive tests that cover the following invariants: ...".
- major505 4y ago
  Thats the thing. Its hard to describe, but you know when you see it.
deleted 4y ago
[deleted]
HideousKojima 4y ago
Also most examples of unit tests that I see in various examples I've seen amounted to testing "Does the code do what the code does?" Unless you have a clear spec to implement, or you have some weird edge cases that you need to make sure get handled correctly, I see very little use in unit tests (integration tests are very helpful though). The only time I've really used unit tests were when we had some specific financial formulas that we were implementing and needed to make sure the code matched them.
jerf 4y ago
Unit tests need to: A. Be taken seriously by the dev team. B. Taken at least moderately seriously by management. Getting the unit tests passing isn't always the most important thing this very second, but they do need to be something we get back to. C. Run automatically, and preferably as a gateway to the commit process. Some sort of automatic continuous integration thing is critical. I have a lot of smaller projects rather than one big project so my CI is often just a git pre-commit hook. This works fine at a small scale; if "CI" is less than ten seconds I think it's advantageous to keep it as local to the dev as possible rather than shoving it off to some external server to complain later. Without these things, they're mostly theatre. With them, they're an incredibly valuable aspect of development that I don't intend to ever develop with ever again, by which I mean, if I do end up taking a job where this wasn't already in place, and I'm not allowed to put it into place, I will shortly be at a new job. Life is too short for the kinds of stupid debugging you have to put in to an untested, uncovered code base. (I don't mind debugging in general. It's a fact of the job. But that pull your hair out every single time, that's an uncovered code base.)
major505 4y ago
PS: dont take me wrong. Unit tests are useful if used properly. But people just don't use it correctly. To most people what is important is the percentage of code tested, instead of test critical logic conditions for your software piece. I work in a big bank in my country, that would insist us to do unit test in UI. Things like, if I set the button visibility to true, the button needs to be visible. Like... no shit Sherlock? What do you expect to happen?

videogreg93 4y ago

Thank you! I feel like all of this Unit test stuff is just a case of Emperor's New Cloths: everyone writes tests, no one knows why but won't admit it. I've never never ever experienced in my life a time where a major problem was automatically found by some unit tests before it got pushed to production.

UK-AL 4y ago
I have. A lot.
- cwilby 4y ago
  Our team too, time saved is fairly quantifiable.
  - disgruntledphd2 4y ago
    I mean, you probably need automated CI before this becomes likely as otherwise people just forget to run the tests...
    - nonethewiser 4y ago
      You absolutely need that.
      - cwilby 4y ago
        Yes, test frequently and automatically.
matthewfcarlson 4y ago
This is sort of why I wrote the article. Professionally, I’ve seen tests just cause tons of noise and offer little benefit. So I tried applying it to a personal project on a whim and found some unexpected benefits
jerf 4y ago
"I've never never ever experienced in my life a time where a major problem was automatically found by some unit tests before it got pushed to production." Then you, or somebody near you, is doing it very wrong. I do not mean this as a moral judgment, I mean it as an engineering process diagnostic feedback. I literally can't count the number of times it has popped up a bug that I wouldn't have expected because of some change. It is that very characteristic that makes me love them so much. No matter how carefully you code you can never get away from the problem of a small change over there causing a breaking over here because of something you couldn't even have anticipated, but you don't have to wait until some large-scale QA process or even production deployment to find out; you can find out 15 seconds later, and then fix it, or realize your new change is fundamentally untenable, or any number of things. I'd say "I don't know how people develop without these things", except I do; the code bases are treated like quick-set concrete and nothing can be changed once laid down. What a stultifying way to code. I would hate to work at a job like that.
- dwaite 4y ago
  > Then you, or somebody near you, is doing it very wrong. I do not mean this as a moral judgment, I mean it as an engineering process diagnostic feedback. IMHO thats the biggest problem with TDD. People often think of TDD as a set of requirements that all push for some set of benefits. But it is really a development methodology where you as a developer heavily utilize tests to drive the development process itself. It is a mindset, not a checklist. Perhaps easiest to explain (with an inaccurate comparison) as - it is like REPL-driven development but with persistent and sharable artifacts. Behavioral driven development is IMHO stronger in this regards, because people tend to understand how the additional artifacts (beyond what you might see with a requirements list or use case document) are part of a methodology. People can better separate the methodology from the benefits/outcome.
- major505 4y ago
  Here is the thing: Most managers want you to implement the test and the code in the same time It would take to write only the code. The thing is, in the end most devs do shit tests becase theres no time allocated to that, and the test end up being just a number that needs to be met so the code could run to the dev ops engine and generte a new version of the software.
nonethewiser 4y ago
I think it can be taken too far but why not have some unit tests? They are the easiest kind of test to write and the fastest to run. Also, you dont see it because those bugs were fixed before production.
spiddy 4y ago
That's because by definition it is not going to be "major" problem since the unit test acted as gateway before it got pushed to production, instead you'll probably be 'meh' and fix it once the unit test fails. This reminds me the saying of a manager arguing why do we need so many SREs since the system is working fine.
dwaite 4y ago
Test driven development on one project would often save me weeks per bug fix. This was because it maintained an environment where I could replicate portions of the business logic (as assembled modules) outside a production environment. This made it much easier to do analysis/fuzzing of one component of the system, vs trying to replicate and do post-mortem crash analysis on the entire deployed system. But I clarify this is TDD, not unit tests. A development methodology where unit tests are wedged in after the fact do not promote the sort of modular programming needed to be able to do this.

donatj 4y ago

> people just write useless tests that test absolutaly nothing usefull, and are worth nothing. Oh man, those are my favorite. They're super difficult to critique in code review. "This test doesn't really test anything" isn't very helpful but writing a proper "do this" is often more work than writing a proper test yourself.

nerdponx 4y ago
Is that not helpful? It's definitely helpful. "This test doesn't do anything", then reject & request changes, "add substantive tests that cover the following invariants: ...".
major505 4y ago
Thats the thing. Its hard to describe, but you know when you see it.

deleted 4y ago

[deleted]

HideousKojima 4y ago

Also most examples of unit tests that I see in various examples I've seen amounted to testing "Does the code do what the code does?" Unless you have a clear spec to implement, or you have some weird edge cases that you need to make sure get handled correctly, I see very little use in unit tests (integration tests are very helpful though). The only time I've really used unit tests were when we had some specific financial formulas that we were implementing and needed to make sure the code matched them.

jerf 4y ago

Unit tests need to: A. Be taken seriously by the dev team. B. Taken at least moderately seriously by management. Getting the unit tests passing isn't always the most important thing this very second, but they do need to be something we get back to. C. Run automatically, and preferably as a gateway to the commit process. Some sort of automatic continuous integration thing is critical. I have a lot of smaller projects rather than one big project so my CI is often just a git pre-commit hook. This works fine at a small scale; if "CI" is less than ten seconds I think it's advantageous to keep it as local to the dev as possible rather than shoving it off to some external server to complain later. Without these things, they're mostly theatre. With them, they're an incredibly valuable aspect of development that I don't intend to ever develop with ever again, by which I mean, if I do end up taking a job where this wasn't already in place, and I'm not allowed to put it into place, I will shortly be at a new job. Life is too short for the kinds of stupid debugging you have to put in to an untested, uncovered code base. (I don't mind debugging in general. It's a fact of the job. But that pull your hair out every single time, that's an uncovered code base.)

major505 4y ago

PS: dont take me wrong. Unit tests are useful if used properly. But people just don't use it correctly. To most people what is important is the percentage of code tested, instead of test critical logic conditions for your software piece. I work in a big bank in my country, that would insist us to do unit test in UI. Things like, if I set the button visibility to true, the button needs to be visible. Like... no shit Sherlock? What do you expect to happen?