4 ms·

Before I go in, I will state that in 99% of the times I'm a TDD hater. Actually I don't even like writing tests after the fact because I just like to build and

Before I go in, I will state that in 99% of the times I'm a TDD hater. Actually I don't even like writing tests after the fact because I just like to build and move on. I could never understand why the ruby on rails tutorial insisted on walking newbies through TDD and skipped all chapters where they start talking about tests when I started learning rails. I still think it's a bad idea to make newbies do all the weird TDD stuff when they don't even know how to build something. I'm so opinionated about this that most people around me know this. And in most cases it works without needing to write any tests. And even if something fails, I can quickly patch it. As long as I wrote the app in a nicely modular way, I've not had much problem. That said, right now I'm working on writing a JS library. And believe it or not, I AM doing TDD right now. I can't believe it myself. I think in cases where the logic involves a lot of intricate details, it's impossible for me to write something without writing tests. I'm not talking about simple web apps. I'm talking about stuff like: template engine, parser, etc. My current setup: I write a test and document it before I write a function. That way I don't get carried away while implementing and know exactly what I'm trying to build. Then I write another function that utilizes that function I just wrote, and so forth. This way I know when the next function doesn't work for some reason I know exactly where something went wrong. Instead going back and debugging every single function used along the way, I know it's the most recent one that's causing the problem. So my conclusion: you probably don't need to write tests for all your stuff, but there are indeed cases where you will NOT be able to proceed without writing tests.

bitL 10y ago
Once you release a product that will be used by many customers and developed by many people throughout its lifecycle, which come and go as the time passes, you won't be able to maintain/extend it without a proper testing suite. It's not only about complexity, but also about maintainability. Some tests will also rot in time.
- cocktailpeanuts 10y ago
  Agreed, in my case what ends up happening is I start out with no tests but soon the project becomes huge and i have to start writing tests if I want to push stuff without fear. The thing is, most large companies have a QA team so this fear is not super tangible to many developers. And small startups are more focused on building stuff quickly (which they should be). I think this is why this topic has been polarizing. Some people feel the need and some people do, depending on which role you're playing in your organization. Nowadays interestingly, even the large companies are moving towards more testing because they can cut QA costs that way.
  - justicezyx 10y ago
    > most large companies have a QA team Not sure what companies you are referring here. Google and Amazon does not have QA team for most of dev team. I worked at Amazon and now work at Google.
    - cocktailpeanuts 10y ago
      There are many other large companies other than Amazon and Google. Just because Google and Amazon don't have QA team doesn't mean the occupation doesn't exist.
      - justicezyx 10y ago
        I do not intend to say QA as an type of engineering position does not exist. What I was responding to is the parent's claim that "most large companies have a QA team so this fear is not super tangible to many developers"; that's not true in general.
        cocktailpeanuts 10y ago
        It's kinda funny I'm even debating about this, I don't know where your confidence comes from. You use the two most edge cases as an example (Amazon and Google). Most other "less techy" companies don't have the luxury to not run QA. Good for you that Google and Amazon doesn't have QA, but those are the exception, not the rule. Just go to glassdoor and search for QA and you'll see tons of QA job positions for large companies. Since you mention Amazon, for example, WalMart has QA engineer positions.
        bitL 10y ago
        Google used to have SETs, likewise MS used to have SDETs, but they dumped them in favor of DevOps which are the new QAs.
        justicezyx 10y ago
        I do not want to nit picking our discussion. But I seem failed to convey my ideas: 1. QA exists prevalently 2. In general software companies do not have dedicated QA team for every engineer team 3. Lack of testing is a real concern for maintainability in big companies, because developers need to write tests themselves. I do not disagree with your examples, but they are orthogonal to my point #2 #3. Let's go back to your original comment: """ The thing is, most large companies have a QA team so this fear is not super tangible to many developers. And small startups are more focused on building stuff quickly (which they should be). """ The comment was responding to: """ Once you release a product that will be used by many customers and developed by many people throughout its lifecycle, which come and go as the time passes, you won't be able to maintain/extend it without a proper testing suite. It's not only about complexity, but also about maintainability. Some tests will also rot in time. """ My understanding is that, you meant to say that the fear of lack of testing harms maintainability is not so relevant to developers in big companies, because they have dedicated QA team (writ tests for them). My comment says, in general, big companies do not have dedicated QA teams for dev teams, so there is no dedicated QA team write tests for dev team. My examples are 2 of the largest software companies in the world. Among them, Google redefined how people access information, Amazon reinvented how developers access computing resources. I think my examples support my intention to prove that your statement and what it implied, in general, is not true.

bitL 10y ago

Once you release a product that will be used by many customers and developed by many people throughout its lifecycle, which come and go as the time passes, you won't be able to maintain/extend it without a proper testing suite. It's not only about complexity, but also about maintainability. Some tests will also rot in time.

cocktailpeanuts 10y ago
Agreed, in my case what ends up happening is I start out with no tests but soon the project becomes huge and i have to start writing tests if I want to push stuff without fear. The thing is, most large companies have a QA team so this fear is not super tangible to many developers. And small startups are more focused on building stuff quickly (which they should be). I think this is why this topic has been polarizing. Some people feel the need and some people do, depending on which role you're playing in your organization. Nowadays interestingly, even the large companies are moving towards more testing because they can cut QA costs that way.
- justicezyx 10y ago
  > most large companies have a QA team Not sure what companies you are referring here. Google and Amazon does not have QA team for most of dev team. I worked at Amazon and now work at Google.
  - cocktailpeanuts 10y ago
    There are many other large companies other than Amazon and Google. Just because Google and Amazon don't have QA team doesn't mean the occupation doesn't exist.
    - justicezyx 10y ago
      I do not intend to say QA as an type of engineering position does not exist. What I was responding to is the parent's claim that "most large companies have a QA team so this fear is not super tangible to many developers"; that's not true in general.
      - cocktailpeanuts 10y ago
        It's kinda funny I'm even debating about this, I don't know where your confidence comes from. You use the two most edge cases as an example (Amazon and Google). Most other "less techy" companies don't have the luxury to not run QA. Good for you that Google and Amazon doesn't have QA, but those are the exception, not the rule. Just go to glassdoor and search for QA and you'll see tons of QA job positions for large companies. Since you mention Amazon, for example, WalMart has QA engineer positions.
        bitL 10y ago
        Google used to have SETs, likewise MS used to have SDETs, but they dumped them in favor of DevOps which are the new QAs.
        justicezyx 10y ago
        I do not want to nit picking our discussion. But I seem failed to convey my ideas: 1. QA exists prevalently 2. In general software companies do not have dedicated QA team for every engineer team 3. Lack of testing is a real concern for maintainability in big companies, because developers need to write tests themselves. I do not disagree with your examples, but they are orthogonal to my point #2 #3. Let's go back to your original comment: """ The thing is, most large companies have a QA team so this fear is not super tangible to many developers. And small startups are more focused on building stuff quickly (which they should be). """ The comment was responding to: """ Once you release a product that will be used by many customers and developed by many people throughout its lifecycle, which come and go as the time passes, you won't be able to maintain/extend it without a proper testing suite. It's not only about complexity, but also about maintainability. Some tests will also rot in time. """ My understanding is that, you meant to say that the fear of lack of testing harms maintainability is not so relevant to developers in big companies, because they have dedicated QA team (writ tests for them). My comment says, in general, big companies do not have dedicated QA teams for dev teams, so there is no dedicated QA team write tests for dev team. My examples are 2 of the largest software companies in the world. Among them, Google redefined how people access information, Amazon reinvented how developers access computing resources. I think my examples support my intention to prove that your statement and what it implied, in general, is not true.