The test design need not be reviewed, but the developer should convince themselves that the test accurately matches the specification for their module.

Developers often misunderstand the necessary level of detail in unit tests, typically doing just enough to insure that the module works.. This is usually grossly insufficient, as this is the only test to insure that the module works perfectly all the time.  A good example is boundary conditions, such as adding elements to a list when the list is nearly full (such as [list_limit - 1]).  This is often difficult to test in regression, especially for every little element of the system, but easy to deal with in unit test.  Even worse, many developer's unit tests don't bother to exercise the error handling mechanisms.  Thus, the unit tests should exercise the module in every conceivable way, including all possible error conditions. 

In addition, the test design should be modular, as more tests will undoubtedly be added over time.  If QA finds a bug in a module, it should be fixed and a tests added to prevent recurrence;  it's amazing how often "fixed" defects come back and the new test will catch them immediately.  Also, it's a good job for an intern or junior developer to continually strengthen the tests based on additional experience and problems that crop up in other modules.