3 ms·

>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

>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/

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/