Unfortunately due to changes in our priorities the test runner is not yet part of the offical release. As general guidelines:
- Unit test you can use always when you don't want to test something in a real environment. Usually this is more or less algorithms, API tests, parsers. Something that has narrow and well defined scope. Whenver you have dependencies they should be mocked. Tests that cover small units of code fit well here. Those are uslually very fast since don't rely on databases, external services and so on. For unit tests the less you need to use mocking tools the better. Instead of calling a a complicated and difficult to instantiate type or a static type, you can provide a simple interface implementation that will provide results needed for the unit test to complete correctly.
- Integraion tests - when you wish to confirm that something works in a real world environment - for example, you create a blog post then you want to see if the RSS feed has been updated, you should write integration test. Important thing here to have in mind is create atomic tests - the system should remain clean after each test. Because here you work with the real environment - database, web server, external services - everthing should be returned to its original state in order not to affect the remaining tests. Also it is good to execute each test in a new request and have in mind that they are slower and harder to maintain. If somethin fails the reason can be harder to be discovered - it can be everyhitng - from functionality bug to wrong database connection.
the Telerik team
Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking
system and vote to affect the priority of the items