{"id":8223,"date":"2015-04-18T08:56:00","date_gmt":"2015-04-18T15:56:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/visualstudioalm\/2015\/04\/18\/smart-unit-tests-test-to-code-binding-test-case-management\/"},"modified":"2022-07-27T06:12:59","modified_gmt":"2022-07-27T14:12:59","slug":"smart-unit-tests-test-to-code-binding-test-case-management","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/devops\/smart-unit-tests-test-to-code-binding-test-case-management\/","title":{"rendered":"Smart Unit Tests – Test to Code Binding, Test Case Management"},"content":{"rendered":"

[Editor\u2019s note: “Smart Unit Tests” has been renamed to \u201cIntelliTest<\/strong>\u201d with effect from Visual Studio 2015 Release Candidate (RC).]<\/em><\/p>\n

In an earlier post<\/a> we had mentioned how Smart Unit Tests can emit a suite of tests for a given code-under-test, and how it can manage this test suite as the code-under-test itself evolves. For any given method serving as the code-under-test, the emitted\u00a0test suite comprises of a “parameterized unit test” and one or more “generated unit tests”, and the\u00a0following\u00a0figure illustrates\u00a0the *Pex** custom attributes used to identify the ***test-to-code binding***, that in turn enables such management. These attributes are defined within the Microsoft.Pex.Framework namespace.<\/p>\n

\"\"<\/p>\n

At compile time, these attributes are baked into the assembly as metadata for the types and methods to which they were applied. On subsequent invocations, Smart Unit Tests can reflect on the assembly and, with the help of this metadata, re-discover the test-to-code binding.<\/span><\/p>\n

As you would have noticed, the generated unit tests are just traditional unit tests; indeed, they will show up in the Visual Studio Test Explorer<\/a> just like any other hand written test, although it is not expected that such generated unit tests will be edited by hand. Each generated unit test calls into the parameterized unit test which then calls into the code-under-test.<\/span><\/p>\n

The programmatic separation between the generated unit tests and the parameterized unit test allows the parameterized unit test to serve as a single location where you can specify correctness properties about the code-under-test, that all of the generated unit tests can validate. In a future post we will discuss ways to express such correctness properties, but it is not a matter of concern for the test-to- code binding, the topic of this post. What does matter is that the generated unit tests and the parameterized unit test are placed into the same assembly.<\/span><\/span><\/p>\n

The management of these generated unit tests involves the following:<\/span><\/span><\/p>\n