Anatomy of SQL Server sixth to avoid regressions in system tests for Orcamdf

The original: Anatomy of SQL Server sixth to avoid regressions in the system test of Orcamdf

Anatomy of SQL Server sixth to avoid regressions in system tests for Orcamdf

http://improve.dk/avoiding-regressions-in-orcamdf-by-system-testing/

The risk of bugs is increasing as I continue to add new features and new data structures to support the Orcamdf software

Especially when I develop a large unknown function, I can't estimate the structure and the structure of the association, in order to reduce the risk, testing is very necessary

Unit Test

Unit testing is a test that tests the smallest part of a feature of a source code in object-oriented programming. An example of a test is the Sqlbigint data type parsing class,

He should look like this.

usingSystem;usingnunit.framework;usingOrcaMDF.Core.Engine.SqlTypes;namespaceorcamdf.core.tests.engine.sqltypes{[Testfixture] Public classsqlbiginttests {[Test] Public voidGetValue () {varType =NewSqlbigint (); byte[] input; Input=New byte[] {0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0x7F }; Assert.AreEqual (9223372036854775807, Convert.toint64 (type.            GetValue (input)); Input=New byte[] {0x82,0x5A,0x03,0x1B,0xd5,0x3e,0xCD,0x71 }; Assert.AreEqual (8200279581513702018, Convert.toint64 (type.            GetValue (input)); Input=New byte[] {0x7F,0xa5,0xFC,0xE4,0x2A,0xC1,0x32,0x8E }; Assert.AreEqual (-8200279581513702017, Convert.toint64 (type.        GetValue (input)); } [Test] Public voidLength () {varType =NewSqlbigint (); Assert.throws<ArgumentException> (() = type. GetValue (New byte[9])); Assert.throws<ArgumentException> (() = type. GetValue (New byte[7])); }    }}

This test contains the main entry point of the Sqlbigint class, testing whether the long bigint data type causes overflow or underflow, and also contains the length check.

For simple Type unit tests like Sqlbigint, it works fine. Sometimes unit testing can be complicated when the associated class needs to call the appropriate method, class, etc. supporting the underlying structure of his run (mock test)

While this is a working strategy, testing needs to be ongoing, especially in the early stages of the project, where the entire architecture is dynamic

System Testing

In the test range, we need a larger range of tests-system testing. System testing is designed to test the system as a whole, essentially ignoring the internal workings of the system

If you want to classify the words can be divided into black box test. For Orcamdf, I estimate that I can capture 90% of all the regressions using only 10% of the time,

Use more time than the unit test to capture only a small amount of regressions.

Therefore, this is a good way to test during development, while also introducing critical unit tests and integration tests.

For example I want to test the parsing of the user table name inside the DatabaseMetaData class, I can simulate the sysobjects value list, and for DatabaseMetaData class

Constructor can also simulate the parameters required by the mdffile, in order to do this, I have to extract an interface from mdffile and use the mocking framework above

The system tests the methods to perform the following processes:

1. Connect to a SQL Server instance

2. Create a test architecture in test fixture

3. Separating the database

4. Run orcamdf and load separate database validation results

A test sample that creates two user tables and verifies the output of the DatabaseMetaData class

usingSystem.Data.SqlClient;usingnunit.framework;usingOrcaMDF.Core.Engine;namespaceorcamdf.core.tests.integration{ Public classparseusertablenames:sqlserversystemtest {[Test] Public voidParsetablenames () {using(varMDF =NewMdffile (Mdfpath)) {                varMetaData =MDF.                GetMetaData (); Assert.AreEqual (2, metaData.UserTableNames.Length); Assert.AreEqual ("MyTable", metadata.usertablenames[0]); Assert.AreEqual ("XYZ", metadata.usertablenames[1]); }        }        protected Override voidrunsetupqueries (SqlConnection conn) {varcmd =NewSqlCommand (@"CREATE TABLE MyTable (ID int); CREATE TABLE XYZ (ID int);", conn); Cmd.        ExecuteNonQuery (); }    }}

This can be tested very quickly in real-life scenarios. Want to test the parsing of forwarded records? Just need to create a new test simply
Write TSQL code to generate the target database state and then validate the scanned table data

Disadvantages of system Testing

Unfortunately, system testing is not a panacea, it also has its drawbacks. One of the most obvious drawbacks is performance.

Unit tests often need to run very quickly, basically allowing you to run them in the background after each file is saved. Each of these system tests takes half a second from the beginning of the bound CPU to the run

Fortunately, they can run in parallel without problems. A four-core machine allows me to run 480 tests per minute. This allows a complete set of tests to be controlled at a reasonable time,

While still maintaining a subset of tests to run quickly. Usually the code changes do not have too much impact on the test

End of the sixth chapter

Anatomy of SQL Server sixth to avoid regressions in system tests for Orcamdf