4 ms·

I actually complete disagree with sillydude. Even though automated tests may make the team be a bit slower while developing, the suite sure as hell makes the co

by spejic 19y ago

I actually complete disagree with sillydude. Even though automated tests may make the team be a bit slower while developing, the suite sure as hell makes the code the team produces more reliable. So, while the speed of development is very important, so is quality of the product you get out there, even when it's something simple. The more small, simple bugs you can get out of the way before launch, the better. So, automated tests are, at least in my opinion, high priority.

richcollins 19y ago
Is there evidence that time spent writing tests improves the quality of the code over time spent reading the code and trying to make sure it is simple and straightforward?
- nmeans 19y ago
  When you've got 30,000 lines of code, you don't always have time to go back through and read all the code to make sure that the particular change you're making doesn't have drastic effects somewhere. Writing good tests means you don't have to find and read the 200 relevant lines of code.
- cwilbur 19y ago
  There's no evidence that reading the code and trying to make sure it is simple and straightforward improves the quality code, for that matter. The quality of the code is a combination of the quality of the programmers and the quality of the processes they use to produce the code. If you have really good programmers, they can use a shoddy process (write, compile, ship) and still produce reasonable quality code; if you have average programmers with a good process (write test, write code, compile, fix warnings, compile, run test suite, fix errors, compile, run test suite, ship), you can produce good code. What I've found is that whether a test will be useful or not depends on the nature of the code. If I'm writing logic code or building a domain-specific language, an automated test suite means the difference between getting it right quickly and taking a long time to get it hopefully probably mostly right. Readability is only one aspect of code quality, and code that does something complex and convoluted will never be simple and straightforward. For that matter, complex, convoluted, and correct is preferable to simple, straightforward, and wrong, and that's the sort of thing that a test suite will tell you.
  - richcollins 19y ago
    I meant reading it as you (re)write it.
    - cwilbur 19y ago
      Even then! I've seen programmers read the code, get it wrong, and rewrite it in a way that introduces bugs. Hell, I've been that programmer. It's clear, it's readable, it's concise, and it's wrong. Readability and correctness are orthogonal concepts.

by spejic 19y ago

richcollins 19y ago

Is there evidence that time spent writing tests improves the quality of the code over time spent reading the code and trying to make sure it is simple and straightforward?

nmeans 19y ago
When you've got 30,000 lines of code, you don't always have time to go back through and read all the code to make sure that the particular change you're making doesn't have drastic effects somewhere. Writing good tests means you don't have to find and read the 200 relevant lines of code.
cwilbur 19y ago
There's no evidence that reading the code and trying to make sure it is simple and straightforward improves the quality code, for that matter. The quality of the code is a combination of the quality of the programmers and the quality of the processes they use to produce the code. If you have really good programmers, they can use a shoddy process (write, compile, ship) and still produce reasonable quality code; if you have average programmers with a good process (write test, write code, compile, fix warnings, compile, run test suite, fix errors, compile, run test suite, ship), you can produce good code. What I've found is that whether a test will be useful or not depends on the nature of the code. If I'm writing logic code or building a domain-specific language, an automated test suite means the difference between getting it right quickly and taking a long time to get it hopefully probably mostly right. Readability is only one aspect of code quality, and code that does something complex and convoluted will never be simple and straightforward. For that matter, complex, convoluted, and correct is preferable to simple, straightforward, and wrong, and that's the sort of thing that a test suite will tell you.
- richcollins 19y ago
  I meant reading it as you (re)write it.
  - cwilbur 19y ago
    Even then! I've seen programmers read the code, get it wrong, and rewrite it in a way that introduces bugs. Hell, I've been that programmer. It's clear, it's readable, it's concise, and it's wrong. Readability and correctness are orthogonal concepts.