4 ms·

If your engineers don‘t write tests you hired the wrong people. Testing is vital. Make a rule: Every change needs to be tested (you can even set up a pre-commit

by thrrr 9y ago

If your engineers don‘t write tests you hired the wrong people. Testing is vital. Make a rule: Every change needs to be tested (you can even set up a pre-commit hook for this. If a class has no test, one has to be written. If tests can not be written easily for a class, it has to be refactored.

tomnipotent 9y ago
So basically you've never worked at an early stage start-up.
k_sh 9y ago
> If your engineers don‘t write tests you hired the wrong people. Disagree - if your engineers don't write tests, you need to clearly state to them that tests are table stakes, and create an environment conducive to the outcome you want (set up CI, make it fast, set aside time for test-writing hackathons). If your engineers don't want to _follow_ that leadership after it's given, then yeah, you hired the wrong people - but don't demonize employees for not doing something they weren't told they need to do.
- saalweachter 9y ago
  If your engineers don't write tests, it also probably means that they are not being rewarded for writing tests or punished for not writing tests; indeed, if they are rewarded for doing things that are not writing tests (such as pushing new features) and they can do those things without writing tests, they are being rewarded for not writing tests. Just telling engineers, "write tests" and then promoting the ones that don't is bad leadership: you need to create an environment where the behaviors you desire are the ones that are promoted.
Clubber 9y ago
It's a matter of cost. Adding good covering unit tests basically doubles your development time. You are paying now for dividends later. In terms of business, you are trying to prove your business model. If your business model is bad, it doesn't matter how well your software is written. You need to prove your business model before you run out of funds. It's a give and take. You really need to understand both the technical aspects and the business aspects to understand why entities might do certain things. Also, people have been writing software without unit tests for decades.
laythea 9y ago
I'm not sure what kind of professional environment you work in but I would argue that the activity of testing is separate to the activity of writing tests, and that, writing tests only forms part of that.
geofft 9y ago
> If tests can not be written easily for a class, it has to be refactored. How do you make sure that the refactored class does the same thing as the old one? Rewriting old code that you don't have test coverage for is way riskier than whatever small change you were going to make to it. I write a lot of code without tests because a lot of legacy codebases aren't set up to be testable, but they work, and it's important to the business that we're able to deliver small bug fixes and incremental improvements on the existing code while we write whatever replacement system we want to write. As I work on them they'll slowly get more testable, but if you're abandoning working code because it has no tests, you're usually making the wrong decision. (Which the author recognizes.)
- ebiester 9y ago
  Characterization tests - Michael Feathers writes about strategies to build tests in "Working Effectively with Legacy Code". If I wanted to be a consultant or contractor again, it would be walking into these situations and essentially building test systems for legacy code. (And if anyone wants to pay me 8,000 a week for a few months...)
- barrkel 9y ago
  Refactorings worthy of the name aren't scoped by class. In fact refactoring is one of the strongest arguments against unit tests; refactoring typically changes the split of responsibilities and alters the articulation points in the design, such that old tests are discarded and new kinds of tests need to be written. Solid integration tests may work, but it's hard to get really good coverage in any reasonable running time from integration tests. These days I try to cover the happy path with a fairly integrated flavour of test, the edge cases around the tricky bits of code, and fairly exhaustive coverage for authentication / authorization code paths, and not a whole lot more.
- brett40324 9y ago
  > How do you make sure that the refactored class does the same thing as the old one? This. This is the problem. The answer, with tests.
  - 9y ago
jedberg 9y ago
> If your engineers don‘t write tests you hired the wrong people. That's great if you have the luxury of time. Good test coverage will definitely save you time in the long run, no doubt about it. But it will cost you dearly in the short term. And if your company's life or death hangs on getting a feature out a couple days sooner, then skipping tests is a perfectly valid thing to do.

by thrrr 9y ago

tomnipotent 9y ago

So basically you've never worked at an early stage start-up.

k_sh 9y ago

> If your engineers don‘t write tests you hired the wrong people. Disagree - if your engineers don't write tests, you need to clearly state to them that tests are table stakes, and create an environment conducive to the outcome you want (set up CI, make it fast, set aside time for test-writing hackathons). If your engineers don't want to _follow_ that leadership after it's given, then yeah, you hired the wrong people - but don't demonize employees for not doing something they weren't told they need to do.

saalweachter 9y ago
If your engineers don't write tests, it also probably means that they are not being rewarded for writing tests or punished for not writing tests; indeed, if they are rewarded for doing things that are not writing tests (such as pushing new features) and they can do those things without writing tests, they are being rewarded for not writing tests. Just telling engineers, "write tests" and then promoting the ones that don't is bad leadership: you need to create an environment where the behaviors you desire are the ones that are promoted.

Clubber 9y ago

It's a matter of cost. Adding good covering unit tests basically doubles your development time. You are paying now for dividends later. In terms of business, you are trying to prove your business model. If your business model is bad, it doesn't matter how well your software is written. You need to prove your business model before you run out of funds. It's a give and take. You really need to understand both the technical aspects and the business aspects to understand why entities might do certain things. Also, people have been writing software without unit tests for decades.

laythea 9y ago

I'm not sure what kind of professional environment you work in but I would argue that the activity of testing is separate to the activity of writing tests, and that, writing tests only forms part of that.

geofft 9y ago

> If tests can not be written easily for a class, it has to be refactored. How do you make sure that the refactored class does the same thing as the old one? Rewriting old code that you don't have test coverage for is way riskier than whatever small change you were going to make to it. I write a lot of code without tests because a lot of legacy codebases aren't set up to be testable, but they work, and it's important to the business that we're able to deliver small bug fixes and incremental improvements on the existing code while we write whatever replacement system we want to write. As I work on them they'll slowly get more testable, but if you're abandoning working code because it has no tests, you're usually making the wrong decision. (Which the author recognizes.)

ebiester 9y ago
Characterization tests - Michael Feathers writes about strategies to build tests in "Working Effectively with Legacy Code". If I wanted to be a consultant or contractor again, it would be walking into these situations and essentially building test systems for legacy code. (And if anyone wants to pay me 8,000 a week for a few months...)
barrkel 9y ago
Refactorings worthy of the name aren't scoped by class. In fact refactoring is one of the strongest arguments against unit tests; refactoring typically changes the split of responsibilities and alters the articulation points in the design, such that old tests are discarded and new kinds of tests need to be written. Solid integration tests may work, but it's hard to get really good coverage in any reasonable running time from integration tests. These days I try to cover the happy path with a fairly integrated flavour of test, the edge cases around the tricky bits of code, and fairly exhaustive coverage for authentication / authorization code paths, and not a whole lot more.
brett40324 9y ago
> How do you make sure that the refactored class does the same thing as the old one? This. This is the problem. The answer, with tests.
- 9y ago

jedberg 9y ago

> If your engineers don‘t write tests you hired the wrong people. That's great if you have the luxury of time. Good test coverage will definitely save you time in the long run, no doubt about it. But it will cost you dearly in the short term. And if your company's life or death hangs on getting a feature out a couple days sooner, then skipping tests is a perfectly valid thing to do.