4 ms·

We've almost stopped unit testing. We still test functionality automatically before releasing anything into production, but we're not doing a unit test in most

We've almost stopped unit testing. We still test functionality automatically before releasing anything into production, but we're not doing a unit test in most cases Our productivity is way up and our failure rates haven't changed. It's increased our time spent debugging, but not by as much as we had estimated that it would. I won't pretend that's a good decision for everyone. But I do think people take test-driven-development a little too religiously and often forget to ask themselves why they are writing a certain unit test. I mean, before I was a manager I was a developer and I also went to a university where a professor once told me I had to unit test everything. But then, another professor told me to always use the singleton pattern. These days I view both statements as equally false.

vacri 9y ago
At one place I work, the target is 80% rather than 100%. Seems to be a saner target than full coverage.
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?

vacri 9y ago

At one place I work, the target is 80% rather than 100%. Seems to be a saner target than full coverage.

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?