9 ms·

The worse the developer, the more tests he'll write. Instead of writing clean code that makes sense and is easy to reason about, he will write long-winded, poo

The worse the developer, the more tests he'll write. Instead of writing clean code that makes sense and is easy to reason about, he will write long-winded, poorly abstracted, weird code that is prone to breaking without an extensive "test suite" to hold the madness together and god forbid raise an alert when some unexpected file over here breaks a function over there. Tests will be poorly written, pointless, and give an overall false sense of security to the next sap who breaths a sigh of relief when "nothing is broken". Of course, that house of cards will come down the first time something is in fact broken. I've worked in plenty of those environments, where there was a test suite, but it couldn't be trusted. In fact, more often than not that is the case. The developers are a constant slave to it, patching it up; keeping it all lubed up. It's like the salt and pepper on a shit cake. Testing what you do and developing ways to ensure its reliable, fault-tolerant and maintainable should be part of your ethos as a software developer. But being pedantic about unit tests, chasing after pointless numbers and being obsessed with a certain kind of code is the hallmark of a fool.

scalatohaskell 9y ago
This hits home with me. Incompetent developers need dogmatisms (100% unit coverage!!!! etc)
- adamlett 9y ago
  No, inexperienced developers need dogmatisms. Subtle difference perhaps, but it's worth remembering that every competent developer started out being inexperienced, and that it's nothing to be ashamed of.
  - scalatohaskell 9y ago
    You are correct. I was once inexperienced and was very dogmatic.
  - lmm 9y ago
    No. We fetishize experience too much. I've known a great many competent inexperienced developers who could weigh tradeoffs and use the right approach to a given task, and a far too many highly experienced developers who destroyed productivity through dogmatism.
    - adamlett 9y ago
      Productivity is not the sole measure of competency, nor necessarily even a very good one. Productivity suffers when time is spent making software robust, secure, and performant, and the reverse is obviously also true. Likewise, short term productivity sometimes suffers when effort is spent to ensure long term productivity. Again the reverse also holds true. The problem is that short term productivity is often the only measure of competency that is immediately visible. Nobody gets recognized for the problems they don't cause.
dublinclontarf 9y ago
I inherited a code base with LOTS of test coverage. Made one small change and everything broke. Looked into the tests, oh the humanity!!! Dropped the test suite entirely, haven't had any issues since. We have VERY good logging and notifications though so anything goes wrong we know all about it.
- FroshKiller 9y ago
  You know all about it at run-time.
- jacques_chester 9y ago
  > Dropped the test suite entirely, haven't had any issues since. That you know about. That bad test suites exist is unarguable. Bad production code exists too, but we don't give up on writing production code.
- wheresvic1 9y ago
  Why not write tests that make sense then? It would definitely help in maintaining the code (not to mention not having to go through the entire code base when debugging a production issue).
- Nomentatus 9y ago
  I knew a guy who used to wire down safety features on old gas stoves. He said similar stuff about how unnecessary these were. He died (along with his daughter) a year or two later because he disregarded what ski areas were and weren't off limits. Something he'd no doubt done before without any problems. You're fine until you aren't.
arekkas 9y ago
> The worse the developer, the more tests he'll write. As always, generalization is the tool of the fool (sorry for the fool part, but it rhymes ;) ). Writing pointless stubs / mocks and testing execution order of statements is definitely a bad pattern, writing many and good functional, e2e and integration tests however is not.
- arekkas 9y ago
  On top of that this statement will lead (some) new developers to just say "oh yeah I don't need tests because the gosus write only a few tests as well". Same pattern can be observed in DOTA or other games where newbies say "oh I don't need wards/intel because pro players don't need it either". The difference is that pro players already know what's going on. Also worth a read while we're at it: https://www.linkedin.com/pulse/20140623171038-114018241-testivus-on-test-coverage https://www.linkedin.com/pulse/20140623171038-114018241-test...
- phyller 9y ago
  100% agree. Full code coverage with acceptance and integration tests is really good. If you can get a test case for every feature that your app is supposed to have you can develop quickly and ship often knowing that nothing will break. Extensive unit tests that don't test what features do but test how features are implemented are usually a waste of time in my opinion, unless there is some complicated and critical algorithm that you need more visibility and protection for. Otherwise the only purpose of those unit tests is to break for good refactors and double dev time. When You are cleaning up tech debt and make hundreds of lines of changes and no acceptance tests break (because everything is still working as it should) but 50 unit tests break... I've wasted so much of my life
- threatofrain 9y ago
  Generalization is at the heart of science. The lack of generalization is one of the most frustrating attacks you can launch on a scientist's empiricism.
  - ska 9y ago
    We are talking about software testing here. To a first approximation, nobody is being empirical, and there is no science being done.
camus2 9y ago
> The worse the developer, the more tests he'll write. Spare us your platitudes. Most developers don't decide the code coverage, the manager or the client does.
- alkonaut 9y ago
  The manager is hopefully also a developer, and listens to his team Else you have a manager that sets arbitrary quality metrics that the dev team doesn't agree are useful then - and that's a way bigger problem. In the case of contractor work where a customer actually buys the code and not just the functinoality - it's very tricky. I have never done contractor work so I'm not aware of how contracts are usually written. How do you set a quality metric? I'd be much more comfortable to agree to third party to judge the quality than to have an arbitrary metric in a contract for e.g. ratio number of comments to code lines, the average number of character in symbol names or the percentage of lines of code covered by tests.
scottschulthess 9y ago
So the worst of us developers out there write tons of tests? We wish. Who cares if it's 80% or 100%, i'd rather inherit a codebase with lots of test coverage than without.
- mianos 9y ago
  I wish to inherit code that is clear, concise and works over any tests thanks. Each to his own.
  - baq 9y ago
    Unit tests are a tool to get the codebase to that point... When used properly.
  - scottschulthess 9y ago
    So you're saying test coverage is a negative? It's not an either or.
    - MereInterest 9y ago
      If I am understanding correctly, he is saying that well-written code requires fewer tests in order to be fully tested. Fully tested is better than untested, assuming that code is fully tested, well written code will require fewer tests. That is my understanding, as it is rather hard to extract a solid argument from his posts.
      - ZeroGravitas 9y ago
        He specifies "any tests", as do several other anti-test posts in this discussion, though often someone will reply to them and assume, like you have done, that they have another complex set of automated tests that they're happy about, and they're only railing against some unspecified subset of automated tests. I'm not sure if that's being over-charitable or not.
      - deleted 9y ago
        [deleted]
koevet 9y ago
> The worse the developer, the more tests he'll write. This is not only wrong, but also dangerous. I agree with the second part of your comment (about being pedantic about the number of unit tests), but a good and comprehensive test suite is fundamental for large projects, especially projects with many moving parts and a large turn-over of people (basically any big enterprise).
- Retric 9y ago
  By far the best codebase I ever worked with had zero test cases, was nearly 30 years olds, been worked on by not just several teams but several companies, had basically zero documentation, and was still easy to read and understand. Unit tests only really catch a tiny fraction of bugs relating to defective code, not poor design, poor market fit, poor understanding of requirements, or any of the other bugs that most often make it into production. They can be a huge benefit to many possibly most projects, but there are no silver bullets, good quality needs competent people given sufficient time and resources and nothing really changes that equation.
  - koevet 9y ago
    Not sure where you are going with this story. Do you mean that tests are useless, because you once worked in a company that thought that a large, test-less codebase was a good idea? Hint: anecdotal fallacy
    - Retric 9y ago
      No, because I have worked with several dozen code bases, hundreds if not thousands of bugs, and Unit Tests are if anything a bad sign associated with code in desperate need of refactoring. They are the uncanny valley of quality. Ed: Unit Tests become more valuable as code quality decreases.
      - jt2190 9y ago
        Hmm... You're capitalizing "Unit Tests" like there's a need to distinguish the difference between those and what I infer is "code that was not Unit Tests that we ran to verify correctness". Am I correct? Are you drawing a distinction? Or did you truly have no code used to verify correctness? Or no automated way to test?
EugeneOZ 9y ago
The worse the developer, the more they sure they can write perfect code which doesn't need any tests because it's perfect and will be perfect even after future changes, even after changes in related code - absolutely perfect code.
threatofrain 9y ago
Any causal phenomena has some number of factors which it depends upon. A test ought to provide large insight to the user with respect to which factors are the most likely culprits to a specific expression of the phenomena, and they also ought help a programmer determine the number of factors at play. If a competent programmer cannot quickly determine how many factors are in play, or if that programmer cannot constrain the number of relevant factors to a humanly manageable number, then I question how insightful the sum of tests were.
sAbakumoff 9y ago
How about SQLite? Hardly anyone could claim that it was built by the team of "bad developers". However: "the SQLite library consists of approximately 122.9 KSLOC of C code. (KSLOC means thousands of "Source Lines Of Code" or, in other words, lines of code excluding blank lines and comments.) By comparison, the project has 745 times as much test code and test scripts - 91596.1 KSLOC."
brightball 9y ago
I've had good experiences here and bad. The absolute worst was when I took over a project that a contract firm had developed and had to work side by side with them for a few months. They were a 100% test shop. The site itself was broken, certain parts of it would literally crash the web server for certain users because the code was so terrible...but they had tests for everything. What's worse, when fixing some of the broken code they got mad at me for making it harder to write tests...because somehow in this mindset a working product was less important than working tests. I've been wary of test nazis ever since.
swalsh 9y ago
"The worse the developer, the more tests he'll write." no.... please..... no..... let's not go down this path. Why does everything have to be extreme? No tests, 100% tests... it's all bollocks. The most robust code I've ever written was 100% because of unit tests. It was a little engine that approved the prior authorization for medications. The unit tests didn't cover 100% of the application. In fact the only bit it did cover was the various use cases in the approval logic. The tests were invaluable in writing the logic, and continued to be invaluable for the maintenance of the project. Tests are a tool. You don't need to use the tool for EVERYTHING, but sometimes it's the best tool for the job. Using it doesn't make you a bad developer, using it badly makes you a bad developer.
- fireflash38 9y ago
  Everytime I've seen these arguments it's been the same: * Bad coding practices lead to bad tests * Bad test practices make development very difficult, since you're constantly chasing your tail They're invariably intertwined. Bad tests can be re-written. Bad code can be rewritten/refactored too, but it tends to have a larger impact on the product (you know, the thing that actually makes you money). However, it seems that a lot of posters see bad tests and say that it's the problem, and therefore most tests are bad. They neglect that bad tests are a smell that what they're testing is probably shit. They're treating (condemning) the symptom, not the cause.
TheCoelacanth 9y ago
Completely disagree. The worst developers don't even care if their code ends up breaking later; as long as it gets past QA now, that's all that matters.
czardoz 9y ago
> The worse the developer, the more tests he'll write. This is obviously wrong. > Tests will be poorly written, pointless, and give an overall false sense of security to the next sap who breaths a sigh of relief when "nothing is broken". Of course, that house of cards will come down the first time something is in fact broken. That's a generalization that does not apply everywhere.
- ksk 9y ago
  It's rather apparent to me anyway, what the OP meant. If I see someone expending an enormous effort writing tests, I'd probably conclude the same, unless I had knowledge of their expertise, in which case, I'd respect their judgement. The OP meant to draw a line which in their mind, distinguishes an expert from a novice. I don't see why so many people are getting all bent out of shape for. >This is obviously wrong. What makes it obviously wrong? It seems to be a personal opinion. >That's a generalization that does not apply everywhere. Does a comment necessarily have to contain statements that apply to every single person in every single situation at every point in time? I think we'd have to delete pretty much all comments on this website then.
sqeaky 9y ago
If we strike your first sentence, "The worse the developer, the more tests he'll write", then I can mostly agree with you. It sounds like you have never worked on a project with no tests and those same developers that write "write long-winded, poorly abstracted, weird code that is prone to breaking". A test suite doesn't eliminate bad code or bad coders, but it does give the better people on the team a handle to grab them by.
jogjayr 9y ago
> The worse the developer, the more tests he'll write. Some of the worst developers I've worked with never wrote any tests. Like zero tests. Actually in one case negative number of tests; the engineer deleted tests I wrote because they were failing the build because of this engineer's (breaking) changes. Every good developer I know writes tests.

scalatohaskell 9y ago

This hits home with me. Incompetent developers need dogmatisms (100% unit coverage!!!! etc)

adamlett 9y ago
No, inexperienced developers need dogmatisms. Subtle difference perhaps, but it's worth remembering that every competent developer started out being inexperienced, and that it's nothing to be ashamed of.
- scalatohaskell 9y ago
  You are correct. I was once inexperienced and was very dogmatic.
- lmm 9y ago
  No. We fetishize experience too much. I've known a great many competent inexperienced developers who could weigh tradeoffs and use the right approach to a given task, and a far too many highly experienced developers who destroyed productivity through dogmatism.
  - adamlett 9y ago
    Productivity is not the sole measure of competency, nor necessarily even a very good one. Productivity suffers when time is spent making software robust, secure, and performant, and the reverse is obviously also true. Likewise, short term productivity sometimes suffers when effort is spent to ensure long term productivity. Again the reverse also holds true. The problem is that short term productivity is often the only measure of competency that is immediately visible. Nobody gets recognized for the problems they don't cause.

dublinclontarf 9y ago

I inherited a code base with LOTS of test coverage. Made one small change and everything broke. Looked into the tests, oh the humanity!!! Dropped the test suite entirely, haven't had any issues since. We have VERY good logging and notifications though so anything goes wrong we know all about it.

FroshKiller 9y ago
You know all about it at run-time.
jacques_chester 9y ago
> Dropped the test suite entirely, haven't had any issues since. That you know about. That bad test suites exist is unarguable. Bad production code exists too, but we don't give up on writing production code.
wheresvic1 9y ago
Why not write tests that make sense then? It would definitely help in maintaining the code (not to mention not having to go through the entire code base when debugging a production issue).
Nomentatus 9y ago
I knew a guy who used to wire down safety features on old gas stoves. He said similar stuff about how unnecessary these were. He died (along with his daughter) a year or two later because he disregarded what ski areas were and weren't off limits. Something he'd no doubt done before without any problems. You're fine until you aren't.

arekkas 9y ago

> The worse the developer, the more tests he'll write. As always, generalization is the tool of the fool (sorry for the fool part, but it rhymes ;) ). Writing pointless stubs / mocks and testing execution order of statements is definitely a bad pattern, writing many and good functional, e2e and integration tests however is not.

arekkas 9y ago
On top of that this statement will lead (some) new developers to just say "oh yeah I don't need tests because the gosus write only a few tests as well". Same pattern can be observed in DOTA or other games where newbies say "oh I don't need wards/intel because pro players don't need it either". The difference is that pro players already know what's going on. Also worth a read while we're at it: https://www.linkedin.com/pulse/20140623171038-114018241-testivus-on-test-coverage https://www.linkedin.com/pulse/20140623171038-114018241-test...
phyller 9y ago
100% agree. Full code coverage with acceptance and integration tests is really good. If you can get a test case for every feature that your app is supposed to have you can develop quickly and ship often knowing that nothing will break. Extensive unit tests that don't test what features do but test how features are implemented are usually a waste of time in my opinion, unless there is some complicated and critical algorithm that you need more visibility and protection for. Otherwise the only purpose of those unit tests is to break for good refactors and double dev time. When You are cleaning up tech debt and make hundreds of lines of changes and no acceptance tests break (because everything is still working as it should) but 50 unit tests break... I've wasted so much of my life
threatofrain 9y ago
Generalization is at the heart of science. The lack of generalization is one of the most frustrating attacks you can launch on a scientist's empiricism.
- ska 9y ago
  We are talking about software testing here. To a first approximation, nobody is being empirical, and there is no science being done.

camus2 9y ago

> The worse the developer, the more tests he'll write. Spare us your platitudes. Most developers don't decide the code coverage, the manager or the client does.

alkonaut 9y ago
The manager is hopefully also a developer, and listens to his team Else you have a manager that sets arbitrary quality metrics that the dev team doesn't agree are useful then - and that's a way bigger problem. In the case of contractor work where a customer actually buys the code and not just the functinoality - it's very tricky. I have never done contractor work so I'm not aware of how contracts are usually written. How do you set a quality metric? I'd be much more comfortable to agree to third party to judge the quality than to have an arbitrary metric in a contract for e.g. ratio number of comments to code lines, the average number of character in symbol names or the percentage of lines of code covered by tests.

scottschulthess 9y ago

So the worst of us developers out there write tons of tests? We wish. Who cares if it's 80% or 100%, i'd rather inherit a codebase with lots of test coverage than without.

mianos 9y ago
I wish to inherit code that is clear, concise and works over any tests thanks. Each to his own.
- baq 9y ago
  Unit tests are a tool to get the codebase to that point... When used properly.
- scottschulthess 9y ago
  So you're saying test coverage is a negative? It's not an either or.
  - MereInterest 9y ago
    If I am understanding correctly, he is saying that well-written code requires fewer tests in order to be fully tested. Fully tested is better than untested, assuming that code is fully tested, well written code will require fewer tests. That is my understanding, as it is rather hard to extract a solid argument from his posts.
    - ZeroGravitas 9y ago
      He specifies "any tests", as do several other anti-test posts in this discussion, though often someone will reply to them and assume, like you have done, that they have another complex set of automated tests that they're happy about, and they're only railing against some unspecified subset of automated tests. I'm not sure if that's being over-charitable or not.
    - deleted 9y ago
      [deleted]

koevet 9y ago

> The worse the developer, the more tests he'll write. This is not only wrong, but also dangerous. I agree with the second part of your comment (about being pedantic about the number of unit tests), but a good and comprehensive test suite is fundamental for large projects, especially projects with many moving parts and a large turn-over of people (basically any big enterprise).

Retric 9y ago
By far the best codebase I ever worked with had zero test cases, was nearly 30 years olds, been worked on by not just several teams but several companies, had basically zero documentation, and was still easy to read and understand. Unit tests only really catch a tiny fraction of bugs relating to defective code, not poor design, poor market fit, poor understanding of requirements, or any of the other bugs that most often make it into production. They can be a huge benefit to many possibly most projects, but there are no silver bullets, good quality needs competent people given sufficient time and resources and nothing really changes that equation.
- koevet 9y ago
  Not sure where you are going with this story. Do you mean that tests are useless, because you once worked in a company that thought that a large, test-less codebase was a good idea? Hint: anecdotal fallacy
  - Retric 9y ago
    No, because I have worked with several dozen code bases, hundreds if not thousands of bugs, and Unit Tests are if anything a bad sign associated with code in desperate need of refactoring. They are the uncanny valley of quality. Ed: Unit Tests become more valuable as code quality decreases.
    - jt2190 9y ago
      Hmm... You're capitalizing "Unit Tests" like there's a need to distinguish the difference between those and what I infer is "code that was not Unit Tests that we ran to verify correctness". Am I correct? Are you drawing a distinction? Or did you truly have no code used to verify correctness? Or no automated way to test?

EugeneOZ 9y ago

The worse the developer, the more they sure they can write perfect code which doesn't need any tests because it's perfect and will be perfect even after future changes, even after changes in related code - absolutely perfect code.

threatofrain 9y ago

Any causal phenomena has some number of factors which it depends upon. A test ought to provide large insight to the user with respect to which factors are the most likely culprits to a specific expression of the phenomena, and they also ought help a programmer determine the number of factors at play. If a competent programmer cannot quickly determine how many factors are in play, or if that programmer cannot constrain the number of relevant factors to a humanly manageable number, then I question how insightful the sum of tests were.

sAbakumoff 9y ago

How about SQLite? Hardly anyone could claim that it was built by the team of "bad developers". However: "the SQLite library consists of approximately 122.9 KSLOC of C code. (KSLOC means thousands of "Source Lines Of Code" or, in other words, lines of code excluding blank lines and comments.) By comparison, the project has 745 times as much test code and test scripts - 91596.1 KSLOC."

brightball 9y ago

I've had good experiences here and bad. The absolute worst was when I took over a project that a contract firm had developed and had to work side by side with them for a few months. They were a 100% test shop. The site itself was broken, certain parts of it would literally crash the web server for certain users because the code was so terrible...but they had tests for everything. What's worse, when fixing some of the broken code they got mad at me for making it harder to write tests...because somehow in this mindset a working product was less important than working tests. I've been wary of test nazis ever since.

swalsh 9y ago

"The worse the developer, the more tests he'll write." no.... please..... no..... let's not go down this path. Why does everything have to be extreme? No tests, 100% tests... it's all bollocks. The most robust code I've ever written was 100% because of unit tests. It was a little engine that approved the prior authorization for medications. The unit tests didn't cover 100% of the application. In fact the only bit it did cover was the various use cases in the approval logic. The tests were invaluable in writing the logic, and continued to be invaluable for the maintenance of the project. Tests are a tool. You don't need to use the tool for EVERYTHING, but sometimes it's the best tool for the job. Using it doesn't make you a bad developer, using it badly makes you a bad developer.

fireflash38 9y ago
Everytime I've seen these arguments it's been the same: * Bad coding practices lead to bad tests * Bad test practices make development very difficult, since you're constantly chasing your tail They're invariably intertwined. Bad tests can be re-written. Bad code can be rewritten/refactored too, but it tends to have a larger impact on the product (you know, the thing that actually makes you money). However, it seems that a lot of posters see bad tests and say that it's the problem, and therefore most tests are bad. They neglect that bad tests are a smell that what they're testing is probably shit. They're treating (condemning) the symptom, not the cause.

TheCoelacanth 9y ago

Completely disagree. The worst developers don't even care if their code ends up breaking later; as long as it gets past QA now, that's all that matters.

czardoz 9y ago

> The worse the developer, the more tests he'll write. This is obviously wrong. > Tests will be poorly written, pointless, and give an overall false sense of security to the next sap who breaths a sigh of relief when "nothing is broken". Of course, that house of cards will come down the first time something is in fact broken. That's a generalization that does not apply everywhere.

ksk 9y ago
It's rather apparent to me anyway, what the OP meant. If I see someone expending an enormous effort writing tests, I'd probably conclude the same, unless I had knowledge of their expertise, in which case, I'd respect their judgement. The OP meant to draw a line which in their mind, distinguishes an expert from a novice. I don't see why so many people are getting all bent out of shape for. >This is obviously wrong. What makes it obviously wrong? It seems to be a personal opinion. >That's a generalization that does not apply everywhere. Does a comment necessarily have to contain statements that apply to every single person in every single situation at every point in time? I think we'd have to delete pretty much all comments on this website then.

sqeaky 9y ago

If we strike your first sentence, "The worse the developer, the more tests he'll write", then I can mostly agree with you. It sounds like you have never worked on a project with no tests and those same developers that write "write long-winded, poorly abstracted, weird code that is prone to breaking". A test suite doesn't eliminate bad code or bad coders, but it does give the better people on the team a handle to grab them by.

jogjayr 9y ago

> The worse the developer, the more tests he'll write. Some of the worst developers I've worked with never wrote any tests. Like zero tests. Actually in one case negative number of tests; the engineer deleted tests I wrote because they were failing the build because of this engineer's (breaking) changes. Every good developer I know writes tests.