4 ms·

It's so obviously self evident that automated tests improve productivity, especially for developers new to a codebase. A developer makes a non trivial change.

by hoten 5y ago

It's so obviously self evident that automated tests improve productivity, especially for developers new to a codebase. A developer makes a non trivial change. How do they know nothing broke? If there are no tests, they must spend an inordinate amount of time learning the entire system / product to gain any confidence they didn't break something, only to likely miss something that a senior team member will point out. The back/forth will take multiple developers time. At worst, it gets punted all the way to a QA team. Could be days. Or, with tests, that happens far less often and the feedback loop can be more like 10 minutes. Of course, tests don't solve onboarding, but they provide nice guard rails.

dboreham 5y ago
This assumes the tests are mostly valid. My experience in recent years has been that they won't be.
- hoten 5y ago
  Of course I'm assuming useful tests, why wouldn't I? Note I don't claim tests completely solve all productivity or onboarding problems. It's just odd to claim it's somehow ~unclear that automated tests aren't good for productivity. Forget the extremes (over testing, too many unit tests vs integration, potential rigidness): tests done right are productivity multipliers. And that's not a "No True Scotsman" retort because the original claim had no qualifiers, and was suggesting that any version of automated tests are orthogonal to developer productivity. All you must do to refute that is think of any codebase you were able to make progress on faster because a test told you what was wrong faster than it'd take you to blame source code and send an email to a developer you maybe have never met yet.
  - toast0 5y ago
    > Of course I'm assuming useful tests, why wouldn't I? Because useful tests seem pretty hard to have in practice. Especially when starting testing for a project without tests and a team without testing experience. Early testing reduces productivity, and the proposed gains may never develop.
  - gregjor 5y ago
    > It's just odd to claim it's somehow ~unclear that automated tests aren't good for productivity. No it's not, because it is unclear. Where's the actual evidence? How do you even define and measure "productivity" in software development? My customers define productivity as "Delivered according to spec on time and within budget." That's the only measurement they care about. As hard as it is for programmers to understand beautiful "clean" code and automated tests are generally not stakeholder priorities. Yes, bad code and no testing has a cost that may have to get paid down the road. I think stakeholders understand that software will fall short of perfection. For a long time the standard practice was unit testing, integration testing, and (if you were lucky) rigorous QA. Plenty of usable software got written that way. There's nothing inherently wrong with TDD and automated testing, and when done right those techniques can reduce the need for more complex testing (integration and QA) and help the team understand what the code is supposed to do. That's not the only way to write good code that works, but it's one way. The problems of defining, measuring, and improving programmer productivity have been known and discussed since the 1960s. We have a set of fairly vague best practices (also known since the 60s/70s) but there's no silver bullet. The problems with developing non-trivial software in team environments mainly come from communication and team dynamics, not from lack of style guides or automated tests. Every little bit can help, of course, but let's not kid ourselves that TDD and automated testing are magic fairy dust.
vaidhy 5y ago
How does the developer know if a failing case is due to a bug or something that needs to be changed? Is the new developer being dropped in with no support and no peer review and asked to make a non-trivial change? If so, then tests are not so useful in an strongly typed environment since interface changes will be caught at compile time. It is not obviously self evident to me.

by hoten 5y ago

dboreham 5y ago

This assumes the tests are mostly valid. My experience in recent years has been that they won't be.

hoten 5y ago
Of course I'm assuming useful tests, why wouldn't I? Note I don't claim tests completely solve all productivity or onboarding problems. It's just odd to claim it's somehow ~unclear that automated tests aren't good for productivity. Forget the extremes (over testing, too many unit tests vs integration, potential rigidness): tests done right are productivity multipliers. And that's not a "No True Scotsman" retort because the original claim had no qualifiers, and was suggesting that any version of automated tests are orthogonal to developer productivity. All you must do to refute that is think of any codebase you were able to make progress on faster because a test told you what was wrong faster than it'd take you to blame source code and send an email to a developer you maybe have never met yet.
- toast0 5y ago
  > Of course I'm assuming useful tests, why wouldn't I? Because useful tests seem pretty hard to have in practice. Especially when starting testing for a project without tests and a team without testing experience. Early testing reduces productivity, and the proposed gains may never develop.
- gregjor 5y ago
  > It's just odd to claim it's somehow ~unclear that automated tests aren't good for productivity. No it's not, because it is unclear. Where's the actual evidence? How do you even define and measure "productivity" in software development? My customers define productivity as "Delivered according to spec on time and within budget." That's the only measurement they care about. As hard as it is for programmers to understand beautiful "clean" code and automated tests are generally not stakeholder priorities. Yes, bad code and no testing has a cost that may have to get paid down the road. I think stakeholders understand that software will fall short of perfection. For a long time the standard practice was unit testing, integration testing, and (if you were lucky) rigorous QA. Plenty of usable software got written that way. There's nothing inherently wrong with TDD and automated testing, and when done right those techniques can reduce the need for more complex testing (integration and QA) and help the team understand what the code is supposed to do. That's not the only way to write good code that works, but it's one way. The problems of defining, measuring, and improving programmer productivity have been known and discussed since the 1960s. We have a set of fairly vague best practices (also known since the 60s/70s) but there's no silver bullet. The problems with developing non-trivial software in team environments mainly come from communication and team dynamics, not from lack of style guides or automated tests. Every little bit can help, of course, but let's not kid ourselves that TDD and automated testing are magic fairy dust.

vaidhy 5y ago

How does the developer know if a failing case is due to a bug or something that needs to be changed? Is the new developer being dropped in with no support and no peer review and asked to make a non-trivial change? If so, then tests are not so useful in an strongly typed environment since interface changes will be caught at compile time. It is not obviously self evident to me.