4 ms·

I don't practice TDD or unit testing, but I deploy code on average more than 5 times every day. Despite not doing TDD or unit testing, I have enough confidence

I don't practice TDD or unit testing, but I deploy code on average more than 5 times every day. Despite not doing TDD or unit testing, I have enough confidence in my code that I spent a month in Greece on honeymoon last year with only a Blackberry, while an average of about 50,000 concurrent users were connected to the chat system I wrote for justin.tv. In that month the system didn't have a single problem. My "secret", if I have one, is that every change I release is very small (maybe 5 or 10 lines of code - 20 lines at the very most). I read and re-read my changes thoroughly before I deploy, and test the new behavior many times. The evolution of the chat system I wrote has been a huge number of very small steps.

DanielBMarkham 17y ago
I'm curious -- were you using a functional language? An OOP language? Something else?
- abstractbill 17y ago
  Python, because of the twisted library - if I was rewriting, I'd probably use Clojure, but at the time I wrote the system there was no widely-used Lisp with an also widely-used non-blocking i/o library.
biohacker42 17y ago
and test the new behavior many times Manually? You can save a lot of time if automate that.
- abstractbill 17y ago
  I do have non-unit tests (but only for things that have actually failed more than once). Specifically, I have a bunch of chat bots that periodically log in to the production chat servers, talk to each other, ban each other, etc, etc, and make sure they get the responses they expect. Yes, new functionality I test manually. I believe the time taken to write tests for things that have never failed is wasted.
  - axod 17y ago
    Agreed. Given the choice of logging or unit testing, logging is probably 100x as important in finding and fixing bugs.
  - Afton 17y ago
    I believe the time taken to write tests for things that have never failed is wasted. Yes yes yes. I've seen a lot of tests that, if they failed, would have meant that a thousand other tests would have also failed, and that test would have been simply more noise.
    - LargeWu 17y ago
      Then you're either a)not testing correctly or b)writing code with too many dependencies, or c)both. If a thousand tests break from a single code change, this should be a code smell that says your architecture needs work. This is where testing gets its real value. Finding bugs is just a side effect of testing. The real value is that testing helps you design good code.
      - run4yourlives 17y ago
        I think he means the reverse though. It's not that a single line of code causes thousands of failures, it's that you'll never get that particular test to fail unless pretty much everything else is failing to, ergo it's a useless test. I don't necessarily disagree with your point, just clarifying.

DanielBMarkham 17y ago

I'm curious -- were you using a functional language? An OOP language? Something else?

abstractbill 17y ago
Python, because of the twisted library - if I was rewriting, I'd probably use Clojure, but at the time I wrote the system there was no widely-used Lisp with an also widely-used non-blocking i/o library.

biohacker42 17y ago

and test the new behavior many times Manually? You can save a lot of time if automate that.

abstractbill 17y ago
I do have non-unit tests (but only for things that have actually failed more than once). Specifically, I have a bunch of chat bots that periodically log in to the production chat servers, talk to each other, ban each other, etc, etc, and make sure they get the responses they expect. Yes, new functionality I test manually. I believe the time taken to write tests for things that have never failed is wasted.
- axod 17y ago
  Agreed. Given the choice of logging or unit testing, logging is probably 100x as important in finding and fixing bugs.
- Afton 17y ago
  I believe the time taken to write tests for things that have never failed is wasted. Yes yes yes. I've seen a lot of tests that, if they failed, would have meant that a thousand other tests would have also failed, and that test would have been simply more noise.
  - LargeWu 17y ago
    Then you're either a)not testing correctly or b)writing code with too many dependencies, or c)both. If a thousand tests break from a single code change, this should be a code smell that says your architecture needs work. This is where testing gets its real value. Finding bugs is just a side effect of testing. The real value is that testing helps you design good code.
    - run4yourlives 17y ago
      I think he means the reverse though. It's not that a single line of code causes thousands of failures, it's that you'll never get that particular test to fail unless pretty much everything else is failing to, ergo it's a useless test. I don't necessarily disagree with your point, just clarifying.