Unit tests during code review are a poor substitute for unit tests during development.
What you're suggesting makes a lot of sense, intuitively. What's the review for? To check that the code is good. What are tests for? To check that the code is good. So why not combine the two?
Bringing code under test is hard work. Writing code that just works at the one thing it's meant to do is one thing; writing code that can be effectively and efficiently tested is another. Just the fact that the code now runs under two scenarios - "real work" and "test" - demands much greater flexibility, demands that that code be capable of standing on its own in a meaningful way.
Writing your code so that it's testable is extra work and skill. Refactoring somebody else's code for testability, when it wasn't written with testability in mind to begin with, can be a major task.
You're duplicating effort between the developer and the reviewer. Presumably, your developer isn't handing his code in for review without at least some level of confidence that it's working. He already needs to test the code. Now, there are different levels and scopes of testing. QA tests the code after the developer and the reviewer. But whatever scope you think is appropriate for the developer and reviewer, it makes no sense for the developer to figure out how to test the code to that level once, but make his tests throwaway and difficult to reproduce, and then bring in the reviewer to develop test again, this time ones that are automated and reproducible. You're just having both of them invest time in writing the same tests - once poorly, once well.
You're turning review into a much longer, more laborious step. If testing is a major part of the review process, what happens when some tests fail? Is the reviewer responsible for getting the tests all running, so she needs to debug the code as well? Or is it going to be ping-ponged back and forth, one writing tests, the other getting them to pass?
Sometimes you can write a whole bunch of tests that are all orthogonal to each other, so you don't need to ping-pong. Reviewer writes a dozen tests, half of them fail, developer fixes the bugs and all the tests remain valid, and pass now. But... plenty of the time, you've got blocker bugs, or bugs that require redesign and API changes, or whatnot. If you're tossing responsibility for passing tests back and forth between reviewer and developer, then you're not actually at the review stage. You're still developing.
Needing to write tests doesn't incentivize more thorough review. It basically means that the deeper you go, the more tests you have to write, and probably they'll be hard tests that need to go deep into the system.
Compare to the developer writing the tests, where his incentive is: if I don't write important tests, the reviewer will point that out in the review.
Even the reviewer will have a much better understanding of the system if she needs to go over thorough tests of the code, then if she needs to decide for herself when she can stop writing deep-digging test and just OK the code review.
If the developer isn't writing unit tests, the reviewer won't either. There are many obstacles to adopting testing as a common practice. Maybe you're under too much pressure, and your code base is hard to bring under test. Maybe you're not that experienced in testing, and feel like you can't afford the learning curve. Maybe you've got an axe murderer sending threatening notes to people who write tests. I don't know!
But whatever the cause is, it's safe to bet that it applies equally to the reviewer and to the developer. If the team is stressed out, the reviewer doesn't have any more time than the developer does (if she does, redistribute the work so people aren't so stressed). If nobody knows how to write unit tests well, the reviewer probably doesn't either (if she does, she should sit down and teach her teammates).
This suggestion sounds like trying to pass the buck from one colleague to another. And I'm just not seeing any way for that to work out well, first and foremost because it's really hard (and unhealthy) to create a situation where one person is the only one who can do testing, and another person can't do any testing at all.
What does work is having the review cover tests as well. If the developer has already written ten tests, it's much more likely the reviewer can help suggest another ten, than if the developer hadn't written any.
And, if testing corner-cases is a major task, it might make sense to distribute that more widely across the team. **Once the code is testable in the first place, writing more tests becomes much much easier. **
Review is a great time to spot corner cases. And, if the reviewer can jump in and write a test for corner cases she finds, then hey - all the better! But generally speaking, assuming that the reviewer can write tests where the developer didn't sounds like a very poor idea.