4 ms·

This. We tend to put a high value on code review, yet some don't value unit testing. Lean in and I'll tell you a secret: ... unit testing is automated, repeat

This. We tend to put a high value on code review, yet some don't value unit testing. Lean in and I'll tell you a secret: ... unit testing is automated, repeatable, code review!

fvdessen 9y ago
Only if the tests and business code are not written by the same engineer.
- dorfsmay 9y ago
  Which they typically no longer are when fixing a bug or refactoring.
mannykannot 9y ago
How many times do you need to repeat the review of a given unit of code? (actually, that would have more chance of catching additional bugs than would rerunning the same unit tests.) Once you change the code, the existing unit tests are, by definition, invalidated (i.e. there is no value to being able to rerun them), while most higher-level testing will retain their validity. You have actually created an argument for automated higher-level testing (the author mentions that his position is often mistaken for an attack on test automation.)
- nradov 9y ago
  No, changing the code doesn't invalidate the unit tests unless the API design contact changes.
  - mannykannot 9y ago
    By definition, unit tests test the implementation. A test at the API design contract level is an integration test. The only place where these are the same thing are pure (side-effect-free) functions that do not call other functions.
blub 9y ago
I don't see such a large overlap between code review and unit testing. Here's an example from one of my code reviews, where I discovered two issues: 1) A relaxed requirement was agreed to by the PO, but the remote developer wasn't aware of that and wrote code to fulfil the original complex requirement. The implementation was harder to understand and touched more areas of the code, leading to issue number 2. 2) By analysing the interactions between multiple units, I was able to determine that the code as implemented was in fact reading a setting too early, when it was not available, thereby having no effect at all compared to the already existing code. Ironically, this exact concern had prompted the negotiation with the PO which resulted in the relaxed requirement. Interestingly the error was not caught by unit tests, because it didn't happen in a single unit. It wasn't caught by integration tests, because that particular online component was mocked and it passed code review by two other developers.
- eric_h 9y ago
  Static analysis is another tool in the toolbox, and invaluable as well.
jryan49 9y ago
Your unit tests check the architecture of the code and the implementation is maintainable? I say that cause that's what I use code reviews for :P
kafkaesq 9y ago
... unit testing is automated, repeatable, code review! Except when it isn't. "Unit tests can be one form of code review (that also happens to have the advantage of being automated and repeatable). But should never be mistaken as substitute for actually understanding what the code does, why it does it and how it got that way. Which requires an incompressible amount of effort, analysis, and plain and pure grit", would be another take on the matter.

This. We tend to put a high value on code review, yet some don't value unit testing. Lean in and I'll tell you a secret: ... unit testing is automated, repeatable, code review!

fvdessen 9y ago

Only if the tests and business code are not written by the same engineer.

dorfsmay 9y ago
Which they typically no longer are when fixing a bug or refactoring.

mannykannot 9y ago

How many times do you need to repeat the review of a given unit of code? (actually, that would have more chance of catching additional bugs than would rerunning the same unit tests.) Once you change the code, the existing unit tests are, by definition, invalidated (i.e. there is no value to being able to rerun them), while most higher-level testing will retain their validity. You have actually created an argument for automated higher-level testing (the author mentions that his position is often mistaken for an attack on test automation.)

nradov 9y ago
No, changing the code doesn't invalidate the unit tests unless the API design contact changes.
- mannykannot 9y ago
  By definition, unit tests test the implementation. A test at the API design contract level is an integration test. The only place where these are the same thing are pure (side-effect-free) functions that do not call other functions.

blub 9y ago

I don't see such a large overlap between code review and unit testing. Here's an example from one of my code reviews, where I discovered two issues: 1) A relaxed requirement was agreed to by the PO, but the remote developer wasn't aware of that and wrote code to fulfil the original complex requirement. The implementation was harder to understand and touched more areas of the code, leading to issue number 2. 2) By analysing the interactions between multiple units, I was able to determine that the code as implemented was in fact reading a setting too early, when it was not available, thereby having no effect at all compared to the already existing code. Ironically, this exact concern had prompted the negotiation with the PO which resulted in the relaxed requirement. Interestingly the error was not caught by unit tests, because it didn't happen in a single unit. It wasn't caught by integration tests, because that particular online component was mocked and it passed code review by two other developers.

eric_h 9y ago
Static analysis is another tool in the toolbox, and invaluable as well.

jryan49 9y ago

Your unit tests check the architecture of the code and the implementation is maintainable? I say that cause that's what I use code reviews for :P

kafkaesq 9y ago

... unit testing is automated, repeatable, code review! Except when it isn't. "Unit tests can be one form of code review (that also happens to have the advantage of being automated and repeatable). But should never be mistaken as substitute for actually understanding what the code does, why it does it and how it got that way. Which requires an incompressible amount of effort, analysis, and plain and pure grit", would be another take on the matter.