What should be done first: code reviews or unit tests?

265 pts.
Tags:
Debugging
Developer
Development
Functional testing
If a developer implements code for some module and wants it reviewed, what should be the order?

1. First unit test the module after designing test cases for the module, debugging and fixing the bugs and then give the modified code for peer code review.

or

2. First do the code review with peers and then go for unit testing?

Why and do you have specific examples?

 

 

 

Answer Wiki

Thanks. We'll let you know when a new response is added.

I would recommend doing the Code Review before unit testing.

Why? Because for junior/new members of a team, you can catch common coding practice errors, share recommended styles, and in general make sure that what the developer is going to test (and presumably fix as necessary) is aligned with the requirements and your business practices and policies.

If the unit testing (and fixing) occurs first, the developer may waste time dealing with known issues, or trying to fix code that will subsequently need to be rewritten anyway to meet specifications. I have found that code reviews after unit testing have completed tend to “allow” variations from practice standards – people are sometimes reluctant to make a developer change working code “just to align with standards”. You can also find sub-optimal code being left alone as “good enough”, when it could have been avoided with a review before unit testing.

IMHO – ideally, a development cycle would have at least the following steps, in this order:
1. Requirements definition
2. Requirements review
3. Design specification
4. Design review
5. Integration/Product Test specifications
6. Integration/Product Test specifications review
7. Coding (can be concurrent with 5-6)
8. Code review (including Unit Test Plan review)
9. Unit test
10. Unit test review
11. Product integration
12. Integration test
13. Integration test review
14. Release
15. Lessons learned review

Each review should have a minimum of two reviewers, and the lead author/developer of the deliverable for each step should actually “present” the materials to the reviewers, not just send out code/docs and ask for comments.

Just my $0.02…

Discuss This Question: 3  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Meandyou
    It may depend on the reason for the code review. If you are looking for things like following standards such as naming contentions and/or coding techniques then I would think you would get "syntax" corrected before it was tested (or it will have to be retested after it is changed). If you are reviewing for documentation, then it may not matter. just my $.02 I
    5,220 pointsBadges:
    report
  • RobinGoldsmith
    Competent code reviews typically find in an hour what testing would have taken ten hours to find. Thus, it’s much more economical first to review the code to clear out a lot of errors and then follow up with testing to double check. Reviews are so much more effective and efficient because they find many errors in a single pass, whereas testing has a lot of stop-start back-and-forth wasted time due to finding only a few errors in each test execution-debugging cycle. Moreover, reviews often find errors that elude typical testing, especially potential security breaches. Caution, though, because many reviews fail to provide such benefits. The least payback comes from reviews that concentrate mainly on superficialities such as coding style and technique, which is a virtually inevitable consequence when all the reviewers have basically similar, coding-only orientations. It’s far more critical for reviewers also to understand how the program will be used and what it’s supposed to accomplish—and then confirm it will do so in ways that don’t invite problems. Authors of downstream programs are good to include as reviewers, as are analysts and users. I’ve found one or two non-coders can contribute productively and tend to keep the review focused on more important issues. Although it at first seems counter-intuitive, review effectiveness usually is diminished when the author leads the review. When leading the review, the author often talks through issues and thus can make them appear less than they later turn out to be when they actually occur in production and the author isn’t there to talk the users and maintenance people past the problem. Also, authors unconsciously lead reviews away from likely problems—things the author didn’t know about, misunderstood, or was uncomfortable with. Furthermore, when the author leads the review, it can suppress reviewers’ revelation of issues—either because they don’t want to seem too critical or because their criticism engenders emotionalism and defensiveness. Te purpose of the review should be to help the author do their best possible work. Ironically, the author who is present as a reviewer but not review leader often turns out to be the most insightful reviewer. Of course, neither code reviews nor testing is likely to catch the biggest source of errors—design errors, which in turn are mainly due to requirements errors. The biggest payoff comes from effective requirements reviews, then from design reviews, and third from code reviews. However, most organizations’ requirements and design reviews are much less effective than presumed. What organizations call ‘requirements’ usually in fact are high-level product/system designs, so the organization probably doesn’t even have REAL, business requirements let alone review them. Moreover, typical requirements and design reviews tend to use only one or two, far weaker-than-realized techniques, which look mainly at form issues such as clarity but do little to spot wrong and overlooked content issues. My book, Discovering REAL Business Requirements for Software Project Success, and related seminars explain how to overcome these weaknesses, including how to use more than 21 ways to review requirements and more than 15 ways to review designs. In addition to catching the common clarity problems, these much more powerful methods also catch issues that are wrong and overlooked.
    145 pointsBadges:
    report
  • carlosdl
    I agree with Kccrosser. I think code reviews should go first. In addition to what has been previously stated; if unit testing is performed first, and then the code review leads to code modifications, you would have to perform unit testing again to ensure that functionality has not been altered with the code modifications.
    69,510 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following