5 ms·

Automated tests aren't the only way to write code with fewer bugs, but they are the easiest way to write such code. Automated tests are also the easiest to have

Automated tests aren't the only way to write code with fewer bugs, but they are the easiest way to write such code. Automated tests are also the easiest to have running constantly, giving you instant feedback when you've broken something. The only downside is that there are some tests (like testing with particular datasets or high-load performance testing) that can be onerous to automate. My personal rule of thumb is that checks for program correctness should all be automatic. Non-automated tests ought to be reserved for testing non-functional requirements (e.g. making sure the service is performant under load, reliability measures like failovers, etc.).

dozzie 10y ago
> Automated tests [...] are the easiest way to write [code with fewer bugs]. Actually, automated tests are best at ensuring the code doesn't have regressions. But writing bug-free code takes much more than just that; it needs thought-out architecture and interfaces, and with those you often can get decent code without automated tests, so no, it's not "the easiest way".
- crdoconnor 10y ago
  They also serve as a form of code documentation (defining expected behavior). When doing TDD, often speed up development owing to the ability to get much quicker feedback on the code you just wrote. Code without tests has a tendency to congeal owing to the massive uncertainty surrounding changing any particular part.
  - dozzie 10y ago
    > They also serve as a form of code documentation (defining expected behavior). Oh, far from it. Tests are not documentation, documentation is documentation. Tests can be treated as a set of examples at best.
    - crdoconnor 10y ago
      Good well explained tests serve well as documentation. I've used them before in lieu of specifications. Bad tests not so much.
js8 10y ago
I disagree, I actually think that in many cases asserts are easier than tests, and many people derive tests from assertions in their head (or use a tool like quickcheck which does it too). Unfortunately, there is too much focus on testing in today's software that tools for assertions are not on the same level as tools for testing. One class of assertions is type checking, but you can also have dynamic assertions while the code is running. OTOH, abstractions are harder, but it only takes one person to invent a good abstraction that covers a huge class of bugs, and others can copy it. Examples of good abstractions that prevent many bugs are arrays with bounds checking, garbage collection, or optional data type.

dozzie 10y ago

> Automated tests [...] are the easiest way to write [code with fewer bugs]. Actually, automated tests are best at ensuring the code doesn't have regressions. But writing bug-free code takes much more than just that; it needs thought-out architecture and interfaces, and with those you often can get decent code without automated tests, so no, it's not "the easiest way".

crdoconnor 10y ago
They also serve as a form of code documentation (defining expected behavior). When doing TDD, often speed up development owing to the ability to get much quicker feedback on the code you just wrote. Code without tests has a tendency to congeal owing to the massive uncertainty surrounding changing any particular part.
- dozzie 10y ago
  > They also serve as a form of code documentation (defining expected behavior). Oh, far from it. Tests are not documentation, documentation is documentation. Tests can be treated as a set of examples at best.
  - crdoconnor 10y ago
    Good well explained tests serve well as documentation. I've used them before in lieu of specifications. Bad tests not so much.

js8 10y ago

I disagree, I actually think that in many cases asserts are easier than tests, and many people derive tests from assertions in their head (or use a tool like quickcheck which does it too). Unfortunately, there is too much focus on testing in today's software that tools for assertions are not on the same level as tools for testing. One class of assertions is type checking, but you can also have dynamic assertions while the code is running. OTOH, abstractions are harder, but it only takes one person to invent a good abstraction that covers a huge class of bugs, and others can copy it. Examples of good abstractions that prevent many bugs are arrays with bounds checking, garbage collection, or optional data type.