3 ms·

I agree on good practices, but often TDD is wasted time. Not on larger systems, but on small systems with limited functionality where you build using principles

I agree on good practices, but often TDD is wasted time. Not on larger systems, but on small systems with limited functionality where you build using principles like SOLID so you always know where the flaw is, even without the test. We used to write an awful lot of tests on everything. When we stopped we increased productivity by almost 60% at almost no cost. As I said, we still work with TDD, but we only do it when it makes sense.

bjpbakker 8y ago
> often TDD is wasted time I'd say it depends. I find that TDD works mostly as the complement to a good type checker. It is extremely useful when the PL has weak or no type checking (eg javascript, ruby, python, c, etc).
de_watcher 8y ago
But having a test framework always ready is useful. There is a "Test Driven Debugging": when you look around a bit inside the production error dumps, then try to reproduce it with a test, then debug the test in a much smaller scope with something heavy like Valgrind or a Record-Replay debugger (https://github.com/mozilla/rr https://github.com/mozilla/rr). If you write tests regularly during development then you can also isolate and test parts fast when something goes wrong in production.
dtech 8y ago
You don't have to do TDD for this to be useful or happen. In my current project we follow a "bug -> reproduce bug in testcase -> fix bug" method for some parts of the code. This has cause quite an extensive test suite to develop for those parts of the system.
- jnurmine 8y ago
  I'm curious... I can see the obvious value of having a testcase for a class of bugs, but a testcase for a particular bug instance which was already fixed earlier does not seem right, so I probably misunderstood something. How often do the tests find a problem? When it does find a problem, doesn't this mean that one hits a bug which existed before? Can you give an example of a case when the test was useful?
  - nhoe98thnuoe 8y ago
    This is known as regression testing, and it's extremely useful. For example, you find some bug where, say, a calculation produces a nonsense result. You fix it, then add a test for what you just fixed. 2 years from now, someone refactors the code and reintroduces the bug because their refactor didn't take into account all of the possible input cases. Your test now catches it. Our regression tests have literally found hundreds of bugs over the years and saved us a lot of time and embarrassment.
    - jnurmine 8y ago
      Thanks. Of course. I see what you meant now.
jrockway 8y ago
I don't think anyone suggested that TDD be used. Here's what you're doing when you debug something with a debugger: 1) Figure out how to get the program into the state where there bug shows itself. 2) Analyze output from the program or its state (via the debugger) to determine whether or not the code changes you made fixed the bug. All testing is is writing a program that gets to the state mentioned in step 1, and having that program do the check you manually do in step 2. Saying that testing is a waste of time implies that finding bugs, getting a program into the state where it shows the bug, and figuring out whether or not the bug is fixed is the easy part, whereas writing a few lines of source code is the hard and time-consuming part. This is unlikely to be true.

bjpbakker 8y ago

> often TDD is wasted time I'd say it depends. I find that TDD works mostly as the complement to a good type checker. It is extremely useful when the PL has weak or no type checking (eg javascript, ruby, python, c, etc).

de_watcher 8y ago

But having a test framework always ready is useful. There is a "Test Driven Debugging": when you look around a bit inside the production error dumps, then try to reproduce it with a test, then debug the test in a much smaller scope with something heavy like Valgrind or a Record-Replay debugger (https://github.com/mozilla/rr https://github.com/mozilla/rr). If you write tests regularly during development then you can also isolate and test parts fast when something goes wrong in production.

dtech 8y ago

You don't have to do TDD for this to be useful or happen. In my current project we follow a "bug -> reproduce bug in testcase -> fix bug" method for some parts of the code. This has cause quite an extensive test suite to develop for those parts of the system.

jnurmine 8y ago
I'm curious... I can see the obvious value of having a testcase for a class of bugs, but a testcase for a particular bug instance which was already fixed earlier does not seem right, so I probably misunderstood something. How often do the tests find a problem? When it does find a problem, doesn't this mean that one hits a bug which existed before? Can you give an example of a case when the test was useful?
- nhoe98thnuoe 8y ago
  This is known as regression testing, and it's extremely useful. For example, you find some bug where, say, a calculation produces a nonsense result. You fix it, then add a test for what you just fixed. 2 years from now, someone refactors the code and reintroduces the bug because their refactor didn't take into account all of the possible input cases. Your test now catches it. Our regression tests have literally found hundreds of bugs over the years and saved us a lot of time and embarrassment.
  - jnurmine 8y ago
    Thanks. Of course. I see what you meant now.

jrockway 8y ago

I don't think anyone suggested that TDD be used. Here's what you're doing when you debug something with a debugger: 1) Figure out how to get the program into the state where there bug shows itself. 2) Analyze output from the program or its state (via the debugger) to determine whether or not the code changes you made fixed the bug. All testing is is writing a program that gets to the state mentioned in step 1, and having that program do the check you manually do in step 2. Saying that testing is a waste of time implies that finding bugs, getting a program into the state where it shows the bug, and figuring out whether or not the bug is fixed is the easy part, whereas writing a few lines of source code is the hard and time-consuming part. This is unlikely to be true.