The advantages of unit testing are well known, giving development teams a safety net to facilitate change, ease integration and supply live documentation.
Unit testing of small logical code is quite easy and can show value quickly.
But in real life, our code will use other classes and components. If this happens, things can get quite fragile and the tests will quickly become system tests.
Examples are classes that use a database, a logging system, web service, and any other external component.
These external components may require complex setup. For example, in order to run a test that uses a database, you must have a running database with tables and data set up correctly for the test.
Because these tests now rely on these external components, they are are very fragile and will ‘break’ fast even if the actual test scenario still works. This can happen for numerous reasons, among others because the database has been modified (perhaps by another test), the web service is not running, or a configuration file is not configured properly.
This leads to numerous failed tests that require high maintenance. As a result, developers lose their faith in unit testing and deliver their code untested.
Typemock Isolator to the Rescue
Typemock Isolator enables developers to unit test all their code by magically disconnecting and isolating external components.
This allows the code to be unit tested, fast, locally and in a stable manner
How does Typemock Isolator Work
Typemock Isolator uses aspect-oriented technology to redirect calls from the real code. This enables developers to define the behavior of the external component required for a tested scenario. For example, you can simulate that the disk is full when writing to a database by instructing Typemock Isolator to throw an OutOfDiskSpaceException when writing to the database. This is a scenario that will be nearly impossible to test without Typemock Isolator. The developer defines the behavior in the actual unit test and Typemock Isolator automatically isolates all required components.
All this is done without any need to change or refactor the production code, which will still call the external components API. However, these APIs will not really run any code and will return scenario-specific values, as defined in the test.
What about other Mocking frameworks?
Other mocking frameworks can only work when a special and complex pattern called Inversion of Control is used. Once you write your code using this pattern, you are able to inject fake objects into it. This is done by creating mock objects and passing them as an argument into the production code. These techniques require more development and complicated code that add complexity to development and maintenance.
If you are looking for a robust solution that will give you the freedom to design your code without using Inversion of Control patterns, you should use Typemock Isolator.
To learn more about Typemock Isolator:
Download Typemock Isolator
See the Developers Guide
Unit Test Patterns for .NET development – Part I
The advantages of unit testing are well known, giving development teams a safety net to facilitate change, ease integration and supply live documentation.