5 ms·

I'm curious - how old are the systems you're working on? In my experience, unit tests don't catch many bugs when the code is fresh. But when it's five years ol

by dcw303 9y ago

I'm curious - how old are the systems you're working on? In my experience, unit tests don't catch many bugs when the code is fresh. But when it's five years old with many modifications over the code base, some dumb little test that you thought was a waste of time is now alerting you to what would have been a horror regression. In other words: Even though it feels like it's slowing you down now, if you write tests while the functionality is still fresh in your mind, and you capture your assertions well, they'll pay off dividends in the future once you've forgotten what some block of code does.

raarts 9y ago
Yeah good luck explaining those 5 years to the business manager.
eksemplar 9y ago
I work in the public sector in Scandinavia and some of our oldest systems still in service run on an old tandem. So some of it is pretty old. This gives us some unique abilities in terms of modeling our productivity of course, because we started measuring before anyone thought up unit testing. Over the past 15 years, unit testing has failed to produce anything positive, and test driven development has been an absolute disaster. That being said, this isn't something which will be universally true. A lot of the software we use isn't build by us, and I'm certainly that a lot of the suppliers on that software use unit tests quite extensively. For the things we build ourselves, however, there has been almost no value in adopting modern test philosophies. You say that systems have to be able to be worked on 5 years from now, but the truth is that most of our systems transport data and rarely live 5 years without getting rewritten to deliver better performance, higher levels of security or simply because the business has changed completely. A lot of it hold very few responsibilities as well, making it extremely obvious what to fix when a service breaks. Don't get me wrong, we've seen problems we wouldn't have with 100% coverage. But that doesn't matter when spending resources fixing them is still a net positive on every account.
- pietro 9y ago
  Do you have any metrics that you can share?

by dcw303 9y ago

raarts 9y ago

Yeah good luck explaining those 5 years to the business manager.

eksemplar 9y ago

I work in the public sector in Scandinavia and some of our oldest systems still in service run on an old tandem. So some of it is pretty old. This gives us some unique abilities in terms of modeling our productivity of course, because we started measuring before anyone thought up unit testing. Over the past 15 years, unit testing has failed to produce anything positive, and test driven development has been an absolute disaster. That being said, this isn't something which will be universally true. A lot of the software we use isn't build by us, and I'm certainly that a lot of the suppliers on that software use unit tests quite extensively. For the things we build ourselves, however, there has been almost no value in adopting modern test philosophies. You say that systems have to be able to be worked on 5 years from now, but the truth is that most of our systems transport data and rarely live 5 years without getting rewritten to deliver better performance, higher levels of security or simply because the business has changed completely. A lot of it hold very few responsibilities as well, making it extremely obvious what to fix when a service breaks. Don't get me wrong, we've seen problems we wouldn't have with 100% coverage. But that doesn't matter when spending resources fixing them is still a net positive on every account.

pietro 9y ago
Do you have any metrics that you can share?