The following section gives best practices for test tools and test framework. The requirement for tools and framework are more than the tests because of the scope of their use (entire team or multiple teams uses it).
 Design Checklist
You should ask yourself the following questions when you are designing any part of the system.  
1. Have you iterated, selecting the best of several attempts rather than the first attempt?
2. Have you tried decomposing the system in several different ways to see which way will work best?
3. Have you approached the design problem both from the top down and from the bottom up?
4. Have you prototyped risky or unfamiliar parts of the system, creating the absolute minimum amount of throwaway code needed to answer specific questions?
5. Have you spiked the system, to convince yourself that the proposed solution is likely to work?
6. Has your design been reviewed, formally or informally, by others?
7. Have you driven the design to the point that its implementation seems obvious?
8. Does the design adequately address issues that were identified and deferred at the architectural level?
9. Is the design stratified into layers?
10. Are you satisfied with the way the program has been decomposed into subsystems, packages, and classes?
11. Are you satisfied with the way the classes have been decomposed into routines?
12. Are classes designed for minimal interaction with each other?
13. Are classes and subsystems designed so that you can use them in other systems?
14. Will the program be easy to maintain?
15. Is the design lean? Are all of its parts strictly necessary?
16. Does the design use standard techniques and avoid exotic, hard-to-understand elements? 17. Overall, does the design help minimize both accidental and essential complexity?
18. Does design make it easy to maintain and extend (high coherency and loose coupling meaning ‘open to extension but closed for modifications’)
19. Are their similar tools or pieces of infrastructure already available in other place (other teams)? Avoid duplication of effort and helps each one to leverage the work done by the others. E.g. Sharing logging infrastructure and base class infrastructure between different tools
20. Does the design take into account the fact that this tool/fx could be of use by others (outside feature area) in the team.

 Unit Testing:
All test tools and framework must have unit tests written with reasonable code coverage before checking in. After the first check in, the goal is to not have a drop in code coverage % for subsequent checkins.

Static analysis:
Make sure your tool/framework is fxcop clean before you check-in.

Code review:
All test tools/framework must be code reviewed by atleast one person before checking in.