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
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…