Objective
The objective of this page is to establish architectural best practices for TopCoder component testing, including unit and reviewer tests, to be reflected in future components and to be factored into existing components.
Status
Request
Requirements
Before establishing specific best practices, it is necessary to determine the requirements to be satisfied by the components testing capabilities that meet those best practices. Only in that context can the recommended practices be appropriately evaluated. This section explains the requirements that the best practices aim to satisfy.
100% Test Automation
Maintenance of Test Code
Testing by Contract
Simplicity
Multiple Uses of Test Code as Internal Unit, External Unit, Regression and Integration
Test Coverage
Use of tools such as nCover and Cobertura to ensure the unit tests are adequately excercising the underlying source code.
Current standard is for 85% test coverage.
Recommendations
This document recommends both a high-level architectural structure for components to follow in their testing approach, and detailed discussion of how to adapt those structure to specific corner cases. It is strongly recommended that components follow these guidelines in their design and their test implementation to ensure long term viability of the test code and the component itself.
Use of Mocks
Interfaces
100% Unit Code Rampup
Dealing with ...
Open issues
Definitions
A few points that we can get mentioned here.
I have seen on the forum a few times people asking how to deal with abstract classes unit testing.
I am not sure how it works in .NET, but in Java the use of interfaces is required for MockObjects. To this end, it is important that the external API for a component be an interface, such that it can be mocked out in other component's unit tests.