3 ms·

I think everyone has something in common though - they all think testing is a waste of time until all the sudden things start not working at all and it isn't!

2-718-281-828 3y ago
which should be an experience almost any software developer makes within one year of developing software
- ninetyninenine 3y ago
  I've worked in start ups where they don't have automated tests. The code quality is not as good. But that imo is not a symptom of lack of tests. It's a symptom of being a start up and the desire to move fast. As for mysterious error or bugs that occur the rate at which we get them in the code is no larger than code with tests. It turns out that manual testing and static checking is mostly enough. I think for most stuff testing is an illusion. It's one of those faith based mantras developers follow without any basis in science. There are a few applications where I feel automated tests are required but they are not the majority of software projects.
  - rightbyte 3y ago
    > It's a symptom of being a start up and the desire to move fast. My take is that you can only move fast when you are not in a hurry. If you are in a hurry, you need to work slower, or things will be messed up with no time to fix it. Thus, usually, there is no need to move fast, since if you can, you are not in a hurry anyway.
  - pydry 3y ago
    I've worked in plenty too. They start out faster. Delivery and quality both decrease almost imperceptibly for a long period. When somebody who understood how everything was built leaves because they got offered 20% more elsewhere, delivery and quality both plunge quite a lot and the decline accelerates. It's incredibly unusual for them to recover delivery speed and quality after not doing automated testing for so long. It's incredibly hard to "bolt on" testing afterwards - both because the culture and context isn't there but also because the tooling and infrastructure can't be built up in a week. Most companies in this state look for quick fixes like: * Elaborate branching strategies * Entirely different versions of the software for different clients (because you're too afraid to upgrade them all). * Ever more infrequent releases. The next step is technical bankruptcy. That's when your devs start whingeing about wanting to do a full rewrite. That's usually the point where you've probably ended up losing money overall by dodging tests. It can work without tests you manage to hit product/market fit before the decline sets in, but I find that companies in this situation often tend to struggle developing and will often stagnate. 1/50 might tap into some undiscovered new market opportunity and hit it out of the park either way but it's rare.
pydry 3y ago
I don't find this attitude to be common. People always agree that testing has value at least in theory. The wrongheaded attitudes I do see a lot are: 1) Testing is a moral imperative rather than an economic investment that should be paying dividends (I think this is what the article is getting at) 2) Unit test all the things. 3) Your tests should follow a shape (like a pyramid) 4) TDD doesn't really work (for my circumstances) 5) "I don't have time to write tests." 6) Test speed is paramount 7) Flakiness is not a bug to be fixed, flakiness is inevitable
- appplication 3y ago
  I would consider myself a TDD type of dude, but not in a dogmatic way because to be honest I find the intent and execution to be self evident, but have never really looked into doing it “properly”. For me, the #1 reason I lean so heavily on tests is that the software I write rarely behaves exactly as I expect and intend. And the beyond that, I will not remember how a piece of code works 6 months or a year from now. Having tests is an easy way to say “ah, this is how that actually works”. Which is relevant whether you’re trying to identify why an edge case is behaving so weird, or because you forgot or never knew how some bit of code worked. As a side benefit, I work with some renegades whose bugs are only stoped because CI begs them not to merge their code, which has introduced a sea of red failures. If we didn’t have tests, we’d find out about these issues in a much different way.
  - pydry 3y ago
    I'm anti-dogma for everything in software, but I have been using TDD more than 90% of the time for the last 3 years. I think this is rare, and it works mostly because I don't do it the orthodox way most of the time. I think orthodox unit test driven development works and works really well about 15-20% of the time - under scenarios where you have stateless code, a simple API with simple inputs and simple outputs and some complex logic underneath it. If you're writing something like a parser, this might be all you need. I use a more unorthodox version of TDD the other 70-80% of the time, constructing what most other people would regard as a combination of a snapshot test and integration test. It's still TDD, but the test might be something like "load web page, enter text in textbox, click button, fix snapshot of the outcome, faking the REST API that gets called". I find this practice to be vanishingly rare, but I also find it pays large dividends. The orthodox way to do that other 70-80% of code is to create a mess of mock objects. I don't think the people who came up with TDD necessarily intended this (with the exception of uncle bob), but I think it's responsible for most of why it doesn't work for most people most of the time.

2-718-281-828 3y ago

which should be an experience almost any software developer makes within one year of developing software

ninetyninenine 3y ago
I've worked in start ups where they don't have automated tests. The code quality is not as good. But that imo is not a symptom of lack of tests. It's a symptom of being a start up and the desire to move fast. As for mysterious error or bugs that occur the rate at which we get them in the code is no larger than code with tests. It turns out that manual testing and static checking is mostly enough. I think for most stuff testing is an illusion. It's one of those faith based mantras developers follow without any basis in science. There are a few applications where I feel automated tests are required but they are not the majority of software projects.
- rightbyte 3y ago
  > It's a symptom of being a start up and the desire to move fast. My take is that you can only move fast when you are not in a hurry. If you are in a hurry, you need to work slower, or things will be messed up with no time to fix it. Thus, usually, there is no need to move fast, since if you can, you are not in a hurry anyway.
- pydry 3y ago
  I've worked in plenty too. They start out faster. Delivery and quality both decrease almost imperceptibly for a long period. When somebody who understood how everything was built leaves because they got offered 20% more elsewhere, delivery and quality both plunge quite a lot and the decline accelerates. It's incredibly unusual for them to recover delivery speed and quality after not doing automated testing for so long. It's incredibly hard to "bolt on" testing afterwards - both because the culture and context isn't there but also because the tooling and infrastructure can't be built up in a week. Most companies in this state look for quick fixes like: * Elaborate branching strategies * Entirely different versions of the software for different clients (because you're too afraid to upgrade them all). * Ever more infrequent releases. The next step is technical bankruptcy. That's when your devs start whingeing about wanting to do a full rewrite. That's usually the point where you've probably ended up losing money overall by dodging tests. It can work without tests you manage to hit product/market fit before the decline sets in, but I find that companies in this situation often tend to struggle developing and will often stagnate. 1/50 might tap into some undiscovered new market opportunity and hit it out of the park either way but it's rare.

pydry 3y ago

I don't find this attitude to be common. People always agree that testing has value at least in theory. The wrongheaded attitudes I do see a lot are: 1) Testing is a moral imperative rather than an economic investment that should be paying dividends (I think this is what the article is getting at) 2) Unit test all the things. 3) Your tests should follow a shape (like a pyramid) 4) TDD doesn't really work (for my circumstances) 5) "I don't have time to write tests." 6) Test speed is paramount 7) Flakiness is not a bug to be fixed, flakiness is inevitable

appplication 3y ago
I would consider myself a TDD type of dude, but not in a dogmatic way because to be honest I find the intent and execution to be self evident, but have never really looked into doing it “properly”. For me, the #1 reason I lean so heavily on tests is that the software I write rarely behaves exactly as I expect and intend. And the beyond that, I will not remember how a piece of code works 6 months or a year from now. Having tests is an easy way to say “ah, this is how that actually works”. Which is relevant whether you’re trying to identify why an edge case is behaving so weird, or because you forgot or never knew how some bit of code worked. As a side benefit, I work with some renegades whose bugs are only stoped because CI begs them not to merge their code, which has introduced a sea of red failures. If we didn’t have tests, we’d find out about these issues in a much different way.
- pydry 3y ago
  I'm anti-dogma for everything in software, but I have been using TDD more than 90% of the time for the last 3 years. I think this is rare, and it works mostly because I don't do it the orthodox way most of the time. I think orthodox unit test driven development works and works really well about 15-20% of the time - under scenarios where you have stateless code, a simple API with simple inputs and simple outputs and some complex logic underneath it. If you're writing something like a parser, this might be all you need. I use a more unorthodox version of TDD the other 70-80% of the time, constructing what most other people would regard as a combination of a snapshot test and integration test. It's still TDD, but the test might be something like "load web page, enter text in textbox, click button, fix snapshot of the outcome, faking the REST API that gets called". I find this practice to be vanishingly rare, but I also find it pays large dividends. The orthodox way to do that other 70-80% of code is to create a mess of mock objects. I don't think the people who came up with TDD necessarily intended this (with the exception of uncle bob), but I think it's responsible for most of why it doesn't work for most people most of the time.