A good code review will examine the code as it is. This can be difficult for the developer who has a good understanding of what they believe they wrote to do.

I covered a lot of your question in my answer trust-factor-in-code-review. I would expect code being review to have been tested by the developer. Further testing should be covered in the various test suites. I'll expand on testing a little as that is your specific question.

I would answer "No, testing is not part of the code review process". However, there are classes of errors that are easier to spot in code reviews than in testing. There are also coding techniques which are more prone to error which can be identified in code reviews. For example a code review can identify poor variable naming which is difficult to automate.

It might be appropriate to review the related unit tests. Things to look for include:

• Do they test the non-trivial functionality?
• Do they test the important functionality?
• Do they test important edge cases?
• Do they reasonably cover success cases?
• Do they reasonably cover failure cases?

For any non-trivial code, you will not be able to cover the full set of functionality in a reasonable amount of time. However, the unit tests should ensure that the code is functional and fails when expected.

Watch for code that implements functionality available in libraries. In addtion to its test cases, library code gets heavily tested though use, and may have important optimizations and safety checks. Either way, your programmer's implementation won't get fixed when the library does. If library functionality needs to be extended, use a wrapper (developed once for the project or organization). Use as much "Not invented here" technology as possible.

As you do reviews generate a check-list of things to checklist. This will help you ensure the code review is good as you can do.

As you identify problems, you may want to produce a checklist of problems individuals generate. Ask for their list of common errors they make and use it. Share your list with them and check future code from that developer for those problems. As the developer develops, problems they have leaned to avoid may be removed from their list.

A good code review will examine the code as it is. This can be difficult for the developer who has a good understanding of what they believe they wrote to do.

I covered a lot of your question in my answer trust-factor-in-code-review. I would expect code being review to have been tested by the developer. Further testing should be covered in the various test suites. I'll expand on testing a little as that is your specific question.

I would answer "No, testing is not part of the code review process". However, there are classes of errors that are easier to spot in code reviews than in testing. There are also coding techniques which are more prone to error which can be identified in code reviews. For example a code review can identify poor variable naming which is difficult to automate.

It might be appropriate to review the related unit tests. Things to look for include:

• Do they test the non-trivial functionality?
• Do they test the important functionality?
• Do they test important edge cases?
• Do they reasonably cover success cases?
• Do they reasonably cover failure cases?

For any non-trivial code, you will not be able to cover the full set of functionality in a reasonable amount of time. However, the unit tests should ensure that the code is functional and fails when expected.

Watch for code that implements functionality available in libraries. In addtion to its test cases, library code gets heavily tested though use, and may have important optimizations and safety checks. Either way, your programmer's implementation won't get fixed when the library does. If library functionality needs to be extended, use a wrapper (developed once for the project or organization). Use as much "Not invented here" technology as possible.

As you do reviews generate a check-list of things to checklist. This will help you ensure the code review is good as you can do.

As you identify problems, you may want to produce a checklist of problems individuals generate. Ask for their list of common errors they make and use it. Share your list with them and check future code from that developer for those problems. As the developer develops, problems they have leaned to avoid may be removed from their list.