6 ms·

The first part of your comment sounds really odd to me. I definitely write tests to check if my code works, among other things. Why do you think that is the wr

• cheez 10y ago
  I spent some time working for one of the biggest names in trading technology and one of the things I learned is that if your code doesn't work on more or less the first try, your design is probably wrong. The implications of that lesson are profound. When something doesn't work as expected, I now check my design and not the code.
  • pc86 10y ago
    > if your code doesn't work on more or less the first try, your design is probably wrong Or you're tired. Or you're just not as focused as you could be. Or you have a deadline. Or you're trying something new. Or you're not fluent in the language yet. Or you're fluent in the language but not the framework. Or you're fluent in the language and framework but not the design pattern (if you use those). Or a whole host of other things. I'm not saying spot-checking the design isn't a good idea, but saying that it's the design more often than the code just doesn't match up with my experience.
    • cheez 10y ago
      The entire idea is to increase the probability that you are correct. So if you're coding tired, you're decreasing that probability. If you're using a framework you're not familiar with, you're decreasing that probability. This is why I mentioned that it was in trading technology: they only get paid to be right.
  • lordnacho 10y ago
    How do you define "the first try"? Surely you're bound to have various trivial issues?
    • cheez 10y ago
      Something along the lines of after fixing obvious stupid things like those trivial issues.
  • d_theorist 10y ago
    I remember once my code worked on the first try. I found it difficult to believe.
    • cheez 10y ago
      One time in uni, I had no access to a computer and wrote an entire b-tree implementation on paper for a course, typed it in and it worked. Based on a true story
      • eveningcoffee 10y ago
        In principle TDD is the opposite of this. Out of curiosity, did you use any debugging on paper for your code?
        • cheez 10y ago
          I can't recall, honestly
    • jimmaswell 10y ago
      I've found it to happen very often the past few years
  • throwayawnotime 10y ago
    Did this comment really deserve a downvote? Upvoting accordingly!
    • pc86 10y ago
      Maybe not, but this one certainly does.
• robotnoises 10y ago
  To me there are two automated testing philosophies: 1. Write tests to prove your code works, which is sometimes referred to as "test-driven development" 2. Write tests to catch any side effects or regressions when altering code Funny thing is that if you write good tests, then the results are pretty much the same regardless of your motivation.
  • marcosdumay 10y ago
    You have to: 1. Have an overall idea of what your software will do before writing the first line of code. 2. Challenge and change any touched assumption from #1 during development when you refine that idea. 3. Test that the program satisfies your refined idea after it's written. 4. Create some assurance you'll keep #3 correct while you write any further code later. However you fulfill those needs, if you got them all, you are good.
• nolemurs 10y ago
  It's not that it's wrong. Having confidence your code works is ultimately the goal. That said, if I just need to know code works, manual, rather than automated testing works just as well, and requires less effort. Automated testing only shows its real value when you go back to change code that was working before. With the manual approach you'd have to retest everything to have any real confidence. With the automated approach you just run a command. I'm a big fan of automated testing, but if I didn't expect to have to ever change code, I wouldn't bother with it.
  • mistermann 10y ago
    Just being the devil's advocate.... > With the manual approach you'd have to retest everything to have any real confidence. This kind of implies that software development before "~tdd" was a complete disorganized gong show of quality especially where refactoring, but in fact that was not the case. There are ways of coding that are more conducive to quality than others. > With the automated approach you just run a command. Once you've written all that code, yes. > if I didn't expect to have to ever change code, I wouldn't bother with it. Usually you don't, in which case the extra effort on testing is wasted, usually.
    • dpark 10y ago
      You usually don't have to make changes to code once you've written it? The only time I ever find that true is when the code is throwaway (ad hoc data crunching for some purpose, scripts to automate some one time tedious process, practice projects just intense to learn a system, etc). I don't think I've ever written anything that was useful for more than, say, a week that didn't get changed later by myself or someone else. The typical claim is that code maintenance is at least 10x as long as the initial write.
    • nolemurs 10y ago
      > This kind of implies that software development before "~tdd" was a complete disorganized gong show of quality especially where refactoring, but in fact that was not the case. The question isn't "do we need to test." Testing can just take the form of running the code manually and making sure the output makes sense, but you do need to test. The question is "do we test automatically or manually." It's the same question regardless of how good your practices are. Note that this is totally distinct from the question of whether or not to use TDD. > Once you've written all that code, yes. I've found that writing tests often doesn't take much longer than testing manually, and rarely takes longer than testing manually twice. Sure, if you obsessively try to test every possible case and input, you'll waste time, but well targeted testing doesn't have to be slow. > Usually you don't, in which case the extra effort on testing is wasted, usually. For non-trivial projects I have an average number of revisions per line of code much closer to 2 than to 1. Sure, some of the code only gets written once and never touched, but other code gets revised multiple times. If you're good at writing tests, the tests will focus on those often revised lines of code. And, again, you have to compare the effort against the effort of manual testing, not against the effort of writing code you've never run and shipping it.
• clifanatic 10y ago
  > Why do you think that is the wrong approach? "Because you should write code that works in the first place!" -- your boss