code review vs unit test
Ideally you want to do both, but if you had to decide would you do code review or unit test and why?
Good unit tests would be preferable. Sometimes, other developers might just take a cursory glance over code that compiles and looks good enough, without thinking of any long-term consequences. Other times it helps spot out something obvious that the developer forgot, but in my experience, the subtle bugs aren't usually caught.
On the other hand, writing good unit tests and making code that is testable takes a lot of time, and some aspects are harder to test than others (e.g GUI behavior)
On the other hand, writing good unit tests and making code that is testable takes a lot of time, and some aspects are harder to test than others (e.g GUI behavior)
Last edited on
The bigger picture is, what development method are you using?
If you're using TDD or BDD, that will determine the kind of test you create. There are trade offs, lots and lots of tests aren't necessarily a good this. But also, if you pick up some open source project somewhere, you can't really change it unless it has tests.
Code reviews? Always. However, the criteria must be clean and adhered to, otherwise it can become a frustrating waste of time and good will. Specifically, a code review is not an opportunity for someone else to impose their style on the code.
If you're using TDD or BDD, that will determine the kind of test you create. There are trade offs, lots and lots of tests aren't necessarily a good this. But also, if you pick up some open source project somewhere, you can't really change it unless it has tests.
Code reviews? Always. However, the criteria must be clean and adhered to, otherwise it can become a frustrating waste of time and good will. Specifically, a code review is not an opportunity for someone else to impose their style on the code.
unit test.
code review is 'does it look nice so we can maintain/edit/etc it'
unit test is 'does it work'.
pretty code that does not work is less good than ugly code that does work.
ideally, even if flawed, the programmers are not completely making a big mess of style. But the beauty is that a unit test will find some bugs. When you find bugs, you look at the code. When you look at the code, if its a giant mess, you fire the programmer. :P
code review is 'does it look nice so we can maintain/edit/etc it'
unit test is 'does it work'.
pretty code that does not work is less good than ugly code that does work.
ideally, even if flawed, the programmers are not completely making a big mess of style. But the beauty is that a unit test will find some bugs. When you find bugs, you look at the code. When you look at the code, if its a giant mess, you fire the programmer. :P
In TDD, unit test is more than "does it work". In TDD, unit test define the interface.
Writing tests without a background philosophy it pointless.
Writing tests without a background philosophy it pointless.
closed account (2z0kLyTq)
| kbw wrote: |
|---|
| Writing tests without a background philosophy it pointless |
If it is not to much trouble, would you elaborate on what you mean by "background philosophy," or maybe give an example.
The main question is, "Why are you writing a test?"
If you can't answer that with simple clarity, you shouldn't be doing it. (See TDD and BDD).
You don't need a formal reason. Let's say I was unhappy with some aspect of Webkit and wanted to change it. Without the existence of tests in the project you can't be sure you haven't broken it.
On the other hand, lets say you wanted to make your change, but suddenly many test started failing because the tests were exhaustive. You wouldn't be able to change it either.
So, before tests are written, you have to be clear on why and how you do it.
If you can't answer that with simple clarity, you shouldn't be doing it. (See TDD and BDD).
You don't need a formal reason. Let's say I was unhappy with some aspect of Webkit and wanted to change it. Without the existence of tests in the project you can't be sure you haven't broken it.
On the other hand, lets say you wanted to make your change, but suddenly many test started failing because the tests were exhaustive. You wouldn't be able to change it either.
So, before tests are written, you have to be clear on why and how you do it.
| would you do code review or unit test and why? |
Unit tests are great at catching bugs in the functionality of the code. But in the real world, that's just scratching the surface. Much of the code deals with error handling and sometimes it's hard or impossible to write a test that generates the error.
Code reviews are less likely to catch subtle functional problems, but they're great for catching bugs in the error handling. I work in a group where everyone is pretty talented and we've been together for 10-20 years. When we do code reviews, I just assume that the programmer has tested the "sunny day scenarios" of the basic functionality. I spend all my time looking at the error handling.
I'll let you in on a secret. In production code, the bugs are in the error handling. We found this out in the 90's while doing some hard core static analysis of programs, including then-popular programs. The analysis found many bugs, nearly all were in error handing code.
Topic archived. No new replies allowed.