3 ms·

That approach only works in the short-term though. When you've got an already large code-base you just 'made work' but with no tests (code-coverage), how do you

That approach only works in the short-term though. When you've got an already large code-base you just 'made work' but with no tests (code-coverage), how do you 'make it faster' or 'make it readable' without breaking things? Especially as you are likely under pressure to be adding new features.

encoderer 13y ago
By being careful? I'm all for tests but tests aren't the ONLY way to write software that you can modify without "breaking things." It does require more time to develop and test, but then again, you're saving some time by not writing and maintaing tests. Again, I believe in automated testing because I think it hedges my risk but I'd caution against believing your own hype that there is only one way to do something..
- benihana 13y ago
  >I'm all for tests but tests aren't the ONLY way to write software that you can modify without "breaking things." What are some other methodologies that can let me change code with the confidence well-written tests give me? Would love to be able to employ them when automated tests aren't feasible.
  - encoderer 13y ago
    I can't speak to your subjective question but there's a lot of software without automated testing that people are completely capable of modifying without breaking. Ask me a real question and not one about the confidence YOU get from something and I'll see if i can't answer it.
  - jalfresi 13y ago
    I believe there is a rather apt quote by someone whose name escapes me right now (C.J.Hoare maybe?). It goes (paraphrasing): "There are two ways to write software. One is to write code that contains no obvious deficiencies, and the second is to write code that obviously contains no deficiencies. The second way is much harder" I always took this as an argument for smaller, composable components that value simplicity over complexity, dumb over smart and composable over monolithic. I personally (not quite there yet!) try to write code in this manner. I find that the more straight forward and simple the code, the less need there is for tests because I can hold the whole of the code base in my head.

encoderer 13y ago

By being careful? I'm all for tests but tests aren't the ONLY way to write software that you can modify without "breaking things." It does require more time to develop and test, but then again, you're saving some time by not writing and maintaing tests. Again, I believe in automated testing because I think it hedges my risk but I'd caution against believing your own hype that there is only one way to do something..

benihana 13y ago
>I'm all for tests but tests aren't the ONLY way to write software that you can modify without "breaking things." What are some other methodologies that can let me change code with the confidence well-written tests give me? Would love to be able to employ them when automated tests aren't feasible.
- encoderer 13y ago
  I can't speak to your subjective question but there's a lot of software without automated testing that people are completely capable of modifying without breaking. Ask me a real question and not one about the confidence YOU get from something and I'll see if i can't answer it.
- jalfresi 13y ago
  I believe there is a rather apt quote by someone whose name escapes me right now (C.J.Hoare maybe?). It goes (paraphrasing): "There are two ways to write software. One is to write code that contains no obvious deficiencies, and the second is to write code that obviously contains no deficiencies. The second way is much harder" I always took this as an argument for smaller, composable components that value simplicity over complexity, dumb over smart and composable over monolithic. I personally (not quite there yet!) try to write code in this manner. I find that the more straight forward and simple the code, the less need there is for tests because I can hold the whole of the code base in my head.