5 ms·

The article doesn't mention the single most import reason for unit testing: to enable you to refactor your code. Without a suite of unit tests, there's no way

by aazaa 7y ago

The article doesn't mention the single most import reason for unit testing: to enable you to refactor your code. Without a suite of unit tests, there's no way to know that your refactor hasn't introduced bugs of some kind. A suite of tests won't necessarily catch every bug you'll introduce, but it will catch many of them. I've seen this repeatedly. I've had many conversations with developers who claim they don't need unit tests. When I ask "How do you refactor?" the answers is usually some variant of "I don't."

hota_mazi 7y ago
You need "tests" to be able to refactor. They don't have to be unit tests.
granshaw 7y ago
There’s more nuance to this - poorly written unit tests (eg excessive mocking and things like testing private methods) actually make it harder to refactor code, and using strongly typed languages vastly reduces the importance of unit testing for refractors (to the point where the IDE can even do things like method extraction for you)
- VBprogrammer 7y ago
  I propose "Granshaw's law". Every time the value of unit tests is discussed the debate over static vs dynamic typing must be looming eerily in the background. That said, as someone who has spent the majority of his career writing dynamically typed code I can definitely recall far more instances where statically typed code has run and worked first time vs times when I've written some code with unit tests and it worked first time.
- Ididntdothis 7y ago
  When I was contractor there was a project where the tests were so extensive and complex that most change was impossible because of the impact on the tests. Testing private methods is especially evil.
  - MaxBarraclough 7y ago
    Perhaps runtime assertions are the best option for private methods. Bake them right in.
notacoward 7y ago
I keep running into the exact inverse: people who seem to believe they only need unit tests (i.e. no functional/integration tests). It's insane. If I had to pick one, I'd go with the more "live" multi-component tests and ditch the unit tests. Unit tests still have value, as a lightweight way to catch dumb errors in future refactors. That's fantastic. Love it. As soon as they cease being lightweight (and the norm seems to be more effort spent creating mocks/stubs than the actual tests) then they fail even in that purpose and just become another impediment to useful work. I'm all for unit tests as part of a full testing meal, but a whole plate full of nothing but unit tests makes me want to throw up.
- mattferderer 7y ago
  I agree. As always, "It Depends". Use the best tool (type of test) to document & test the business or technical rules being requested. Tests help teams (and future-self of the individual who wrote the code) understand why certain code was implemented & what purpose it is meant to solve. As the business changes the rules they want implemented, having well written out tests seem to help significantly with handling those rules. It also helps when you want to refactor for the sake of code understanding & readability. It is often the case where both developers & those requesting the changes forget why some of the rules were put in place to begin with.
- kraftman 7y ago
  I think mocks in unit tests are a code smell, that indicates that the business logic has not been correctly isolated from the rest of the code, or that the code shouldn't be unit tested at all, and should instead be component/integration tested.
  - closeparen 7y ago
    Most architectural guidance encourages separation of concerns into layers (handler, controller, gateway, etc). Each layer consumes the next. You will be hard pressed to unit test one layer without injecting a mock of the layer below. When the layer is essentially pro forma and has no logic of its own, this is excruciating, but the line coverage number rules all.
VBprogrammer 7y ago
There is also the chicken and egg problem where it's hard to write good unit tests for code which is poorly abstracted and in need of refactoring.
- rjkennedy98 7y ago
  Unit tests also force code to be written in a way it can be refactored and is abstracted at a (somewhat) reasonable level. Its very hard to get test coverage on a 2000 line mega-function.
- kraftman 7y ago
  Fixing bad code is like repairing an old building, you have to put in the scaffolding and supports (int/component tests) first to make sure it stays up before you gut it and check whats salvageable (refactoring and unit tests)
- adrianmonk 7y ago
  Any form of maintenance or cleanliness is basically bistable. Start off with things clean, consistently try to keep it that way, and it's actually pretty easy and not too much effort. Start off with a mess, or start off clean but then neglect things for a while, and you will wind up at the bottom of a hole that it is going to be a long, painful slog to dig yourself out of. This applies to tons of things: coding, keeping your bathroom clean, car and home maintenance, personal relationships, financial management and record-keeping, etc.

by aazaa 7y ago

hota_mazi 7y ago

You need "tests" to be able to refactor. They don't have to be unit tests.

granshaw 7y ago

There’s more nuance to this - poorly written unit tests (eg excessive mocking and things like testing private methods) actually make it harder to refactor code, and using strongly typed languages vastly reduces the importance of unit testing for refractors (to the point where the IDE can even do things like method extraction for you)

VBprogrammer 7y ago
I propose "Granshaw's law". Every time the value of unit tests is discussed the debate over static vs dynamic typing must be looming eerily in the background. That said, as someone who has spent the majority of his career writing dynamically typed code I can definitely recall far more instances where statically typed code has run and worked first time vs times when I've written some code with unit tests and it worked first time.
Ididntdothis 7y ago
When I was contractor there was a project where the tests were so extensive and complex that most change was impossible because of the impact on the tests. Testing private methods is especially evil.
- MaxBarraclough 7y ago
  Perhaps runtime assertions are the best option for private methods. Bake them right in.

notacoward 7y ago

I keep running into the exact inverse: people who seem to believe they only need unit tests (i.e. no functional/integration tests). It's insane. If I had to pick one, I'd go with the more "live" multi-component tests and ditch the unit tests. Unit tests still have value, as a lightweight way to catch dumb errors in future refactors. That's fantastic. Love it. As soon as they cease being lightweight (and the norm seems to be more effort spent creating mocks/stubs than the actual tests) then they fail even in that purpose and just become another impediment to useful work. I'm all for unit tests as part of a full testing meal, but a whole plate full of nothing but unit tests makes me want to throw up.

mattferderer 7y ago
I agree. As always, "It Depends". Use the best tool (type of test) to document & test the business or technical rules being requested. Tests help teams (and future-self of the individual who wrote the code) understand why certain code was implemented & what purpose it is meant to solve. As the business changes the rules they want implemented, having well written out tests seem to help significantly with handling those rules. It also helps when you want to refactor for the sake of code understanding & readability. It is often the case where both developers & those requesting the changes forget why some of the rules were put in place to begin with.
kraftman 7y ago
I think mocks in unit tests are a code smell, that indicates that the business logic has not been correctly isolated from the rest of the code, or that the code shouldn't be unit tested at all, and should instead be component/integration tested.
- closeparen 7y ago
  Most architectural guidance encourages separation of concerns into layers (handler, controller, gateway, etc). Each layer consumes the next. You will be hard pressed to unit test one layer without injecting a mock of the layer below. When the layer is essentially pro forma and has no logic of its own, this is excruciating, but the line coverage number rules all.

VBprogrammer 7y ago

There is also the chicken and egg problem where it's hard to write good unit tests for code which is poorly abstracted and in need of refactoring.

rjkennedy98 7y ago
Unit tests also force code to be written in a way it can be refactored and is abstracted at a (somewhat) reasonable level. Its very hard to get test coverage on a 2000 line mega-function.
kraftman 7y ago
Fixing bad code is like repairing an old building, you have to put in the scaffolding and supports (int/component tests) first to make sure it stays up before you gut it and check whats salvageable (refactoring and unit tests)
adrianmonk 7y ago
Any form of maintenance or cleanliness is basically bistable. Start off with things clean, consistently try to keep it that way, and it's actually pretty easy and not too much effort. Start off with a mess, or start off clean but then neglect things for a while, and you will wind up at the bottom of a hole that it is going to be a long, painful slog to dig yourself out of. This applies to tons of things: coding, keeping your bathroom clean, car and home maintenance, personal relationships, financial management and record-keeping, etc.