This article is based on Roy osherove's "simplified database unit testing using Enterprise Services" article, the source address: http://weblogs.asp.net/rosherove/articles/dbunittesting.aspx
I. Themes
This article introduces a unit test method for the data access layer on the. NET platform, based on Enterprise Services, and nunit, to understand and master the advantages and disadvantages of the test method and the specific implementation method.
With the development of software engineering and Software Design Technology and the needs of actual software projects or products, the testing tools and methods in the testing technology have undergone earth-shaking changes. Test driven development is introduced, which advances the design of the test scheme before writing the code. The design is verified and the design is deduced from the test perspective; at the same time, the test scheme is regarded as the behavior criterion, and each step of code writing can be effectively used to verify its correctness in real time and realize the "small step" in the software development process.
Unit testing is the source of TDD. This article is a unit test method for data access layer testing.
II. Introduction to the unit test method of common data access layer:
The data access layer generally has a large number of crud (create, retrieve, update, delete) methods in a single class. The general test method will bring about the following problems. Mainly include:
1. Junk data; 2. Other tests are affected; 3. Tests are started from unknown conditions.
Common methods to solve the above problems: 1. Undo your Crud method in the test code. 2. manually delete (the most common method): this will add the opposite Operation Method to your test at the end of each test case. This method will bring about the following problems: A. There is no ready-made method for the opposite operation method (you need to write the stored procedure or ado by yourself. ).
3. implement with the transaction object in ADO. Net: Use transactions and rollback to process each of your data operations in each test. This method causes the following problems: A. You need to worry about the impact of the transaction objects in your test case on the internal transactions contained in the tested method. (The command mode can solve this problem. See test Drivern development with Micrsoft. Net by James Newkirk.) it contains many transaction management classes ).
Iii. Test Data access layer of COM + Enterprise Services
To solve these disadvantages, we can use COM + Enterprise Services to test the data access layer.
First, use system. Enterprise Services and nunit to write the basic classes of test cases as follows:
Namespace transactiontesting {
[Testfixture]
[Transaction (transactionoption. Required)]
Public class databasefixture: servicedcomponent
{
[Teardown]
Public void transactionteardown (){
If (contextutil. isintransaction ){
Contextutil. setabort ();}}
}}
The above code is explained as follows: 1. The base class inherits from transactionoption. Required (it uses the automatic transaction processing of COM +)
2. Use [testfixture] and transaction (transactionoption. required)] When initializing and calling this class, COM + will automatically create a transaction context object and add it to the existing transaction list.
3. Call contextutil. setabort () in the teardown method ().
4,
Note:The test project must have a strong name.
After the preceding operations, the following occurs:
1. Before each test, open the transaction context object and add the test class to an existing transaction;
2. The test is executed;
3. At the end of the test, the teardown method is executed and the transaction is rolled back.
Second, set a strong name.
Use sn.exe-K to create a password file and open assemblyinfo in the test project. CS setting attribute [Assembly: assemblykeyfile (@".. /.. /.. /test. SNK ")]; set the static version attribute and modify" 1. 0. * "is [Assembly: assemblyversion (" 1.0.0 ")].
Then, write the test code
The test class must inherit the databasefixture written above, and other test methods should be compiled according to the nunit specification.
Iv. Defects of this method 1. The ADO. Net driver is required to support distributed transactions (for example, MS-acess is not supported)
2. The tested method uses Enterprise Services and sets transaction attribute ("disabled", "not supported", and "requires new "). 3. The tested method itself has DDL statements that do not participate in distributed transactions (terms define and manage objects in the database, such as create, alter, and drop, because DDL operations are implicitly committed and cannot be rolled back ).
