3 ms·

How do you test your code?

by crummy 11y ago

nikolay 11y ago
Honestly? Mainly, reviewing it and debugging it in my mind. It works - you should try it! It makes you a smarter and a better developer as well. The try-refresh-repeat cycle is for amateurs. But that comes with the way I write my code - modular, i.e. broken into small, readable and reusable units. Well, if I'm doing a something that requires shaving off any redundant CPU cycle, that's another story, but as we know, premature optimization is the root of all evil. You won't see anywhere in my code long functions/methods, endlessly nested IF-THENs, and similar junk - writing simple, unfancy, DRY code drops the need for unit tests to almost zero. Using long, but meaningful identifiers drop the need for inline documentation. I mean, I don't have to repeat things that have been known for ages - just buy some old books, it's all in there! There are way too many coders today and very few engineers!
- onion2k 11y ago
  I mean, I don't have to repeat things that have been known for ages - just buy some old books, it's all in there! I don't really understand this point. UnitTest and SUnit, that all subsequent unit testing frameworks are based on, were released in about 1990. "Extreme Programming" was a big thing in the mid-90s and that featured test frameworks as a core component. Automated testing isn't new. There are plenty of old books that advocate exactly the "new and trendy" processes you decry. If your argument is "Write code like engineers did 20+ years ago!", then that includes automated testing. I strongly suspect that we're not actually that far apart in our thinking. I don't believe that unit tests magically make your code better. You can't develop a solution to a problem you don't fully understand by throwing more and more tests at it. Developers still need to take the time to think. I believe a lot of my enthusiasm for testing comes from the belief (...experience...) that there are plenty of developers out there who, as you put it it, are coders rather than engineers. My tests pick up their mistakes (and mine, because sometimes I'm not at my best). Maybe, if you're very fortunate, you've managed to surround yourself with a team who are all really good engineers who genuinely don't need to test things because they're rigorous to the point of infallibility. I haven't, and I work in an industry that means I probably never will, so tests are necessary. Advocating testing is much, much more productive, and will lead to better software in the long run, than advocating developers write better code.
  - nikolay 11y ago
    Just because unit testing existed in the 90s, it doesn't mean it was widely (ab)used as it is now! Many technologies were invented well before they gained adoption. I didn't mean unit testing is new or useless - just that it's being abused ignoring the benefit-cost ratio and negatively affecting you thought process to rely on something unreliable instead on focusing on code quality - tests are no panacea as code today is more tested than ever, but is also buggier than ever as well. As a summary: Just think more when you write code, don't get into the vicious circle of try-refresh-repeat, and having tests in place is no excuse for poor code.

How do you test your code?

by crummy 11y ago

How do you test your code?

Honestly? Mainly, reviewing it and debugging it in my mind. It works - you should try it! It makes you a smarter and a better developer as well. The try-refresh-repeat cycle is for amateurs. But that comes with the way I write my code - modular, i.e. broken into small, readable and reusable units. Well, if I'm doing a something that requires shaving off any redundant CPU cycle, that's another story, but as we know, premature optimization is the root of all evil. You won't see anywhere in my code long functions/methods, endlessly nested IF-THENs, and similar junk - writing simple, unfancy, DRY code drops the need for unit tests to almost zero. Using long, but meaningful identifiers drop the need for inline documentation. I mean, I don't have to repeat things that have been known for ages - just buy some old books, it's all in there! There are way too many coders today and very few engineers!

onion2k 11y ago
I mean, I don't have to repeat things that have been known for ages - just buy some old books, it's all in there! I don't really understand this point. UnitTest and SUnit, that all subsequent unit testing frameworks are based on, were released in about 1990. "Extreme Programming" was a big thing in the mid-90s and that featured test frameworks as a core component. Automated testing isn't new. There are plenty of old books that advocate exactly the "new and trendy" processes you decry. If your argument is "Write code like engineers did 20+ years ago!", then that includes automated testing. I strongly suspect that we're not actually that far apart in our thinking. I don't believe that unit tests magically make your code better. You can't develop a solution to a problem you don't fully understand by throwing more and more tests at it. Developers still need to take the time to think. I believe a lot of my enthusiasm for testing comes from the belief (...experience...) that there are plenty of developers out there who, as you put it it, are coders rather than engineers. My tests pick up their mistakes (and mine, because sometimes I'm not at my best). Maybe, if you're very fortunate, you've managed to surround yourself with a team who are all really good engineers who genuinely don't need to test things because they're rigorous to the point of infallibility. I haven't, and I work in an industry that means I probably never will, so tests are necessary. Advocating testing is much, much more productive, and will lead to better software in the long run, than advocating developers write better code.
- nikolay 11y ago
  Just because unit testing existed in the 90s, it doesn't mean it was widely (ab)used as it is now! Many technologies were invented well before they gained adoption. I didn't mean unit testing is new or useless - just that it's being abused ignoring the benefit-cost ratio and negatively affecting you thought process to rely on something unreliable instead on focusing on code quality - tests are no panacea as code today is more tested than ever, but is also buggier than ever as well. As a summary: Just think more when you write code, don't get into the vicious circle of try-refresh-repeat, and having tests in place is no excuse for poor code.