5 ms·

A similar question, whose answer will likely be revealing, is: How much time do you spend manually testing? Or, worse, how much time do your users spend/waste

A similar question, whose answer will likely be revealing, is: How much time do you spend manually testing? Or, worse, how much time do your users spend/waste on bugs? Note the key difference here: invest vs. spend. Time spent on writing good automated tests is an investment. That investment pays dividends every time the test suite is ran. On the other hand, time spent manually testing is lost. If you ever want to run the same test, you have to spend the same amount of time. I gave a presentation on continuous integration and testing at PyOhio that goes into this idea in more depth: https://m.youtube.com/watch?v=K-iii4kMLWE https://m.youtube.com/watch?v=K-iii4kMLWE To answer your question: as much as it takes. We work hard to never ship code that isn't well tested. I don't even think in terms of writing code without tests anymore, the testing is just a part of the overall process needed to finish the job.

amirathi 9y ago
>Note the key difference here: invest vs. spend. Time spent on writing good automated tests is an investment. That investment pays dividends every time the test suite is ran. On the other hand, time spent manually testing is lost. If you ever want to run the same test, you have to spend the same amount of time. Well I totally understand the benefits of automated testing. That's not the point here. My motivation for asking this question was to see how much time does it take for others to write automated tests (measured as % of time spent in coding the feature itself). If it's significant chunk of time, can we build some tooling to speed up this process?
- ajeet_dhaliwal 9y ago
  As a percentage it is high and I think that’s the main reason some teams try to get away without doing it. I’d estimate 25-50% at least depending on the complexity of the feature. The point above is valid though, how much time was spent dealing with the fall out of not writing tests? Not easy to measure unless people are meticulous about tracking hours over numerous releases which probably doesn’t happen. Leads and managers need to see the ROI in a visible and measurable way.
  - deleted 9y ago
    [deleted]
- afarrell 9y ago
  I suspect that building tooling, as in things to automate test-generation, likely only going to be successful in situations which cry out for some duplication to be eliminated. A thing that can be done is to improve the way that the frameworks we use support testability. For instance, the company I'm at felt like rails controllers had gotten hard to write tests for and so they replaced them with https://github.com/gocardless/coach https://github.com/gocardless/coach. Here's a blog post if you're interested in using it: https://gocardless.com/blog/getting-started-with-coach/ https://gocardless.com/blog/getting-started-with-coach/

amirathi 9y ago

>Note the key difference here: invest vs. spend. Time spent on writing good automated tests is an investment. That investment pays dividends every time the test suite is ran. On the other hand, time spent manually testing is lost. If you ever want to run the same test, you have to spend the same amount of time. Well I totally understand the benefits of automated testing. That's not the point here. My motivation for asking this question was to see how much time does it take for others to write automated tests (measured as % of time spent in coding the feature itself). If it's significant chunk of time, can we build some tooling to speed up this process?

ajeet_dhaliwal 9y ago
As a percentage it is high and I think that’s the main reason some teams try to get away without doing it. I’d estimate 25-50% at least depending on the complexity of the feature. The point above is valid though, how much time was spent dealing with the fall out of not writing tests? Not easy to measure unless people are meticulous about tracking hours over numerous releases which probably doesn’t happen. Leads and managers need to see the ROI in a visible and measurable way.
- deleted 9y ago
  [deleted]
afarrell 9y ago
I suspect that building tooling, as in things to automate test-generation, likely only going to be successful in situations which cry out for some duplication to be eliminated. A thing that can be done is to improve the way that the frameworks we use support testability. For instance, the company I'm at felt like rails controllers had gotten hard to write tests for and so they replaced them with https://github.com/gocardless/coach https://github.com/gocardless/coach. Here's a blog post if you're interested in using it: https://gocardless.com/blog/getting-started-with-coach/ https://gocardless.com/blog/getting-started-with-coach/