Implementing the tests

Now that we have an empty fixture in place and have seen how to run tests, we are ready to do some more interesting things in our test methods:

void TestOne() 
{
  const wchar_t* testString = L"test";
  
  //
  // Use typesafe assertions...
  //
  CFIXCC_ASSERT_EQUALS( 1, 1 );
  CFIXCC_ASSERT_EQUALS( L"test", testString );
  CFIXCC_ASSERT_EQUALS( wcslen( testString ), ( size_t ) 4 );
  
  //
  // ...log messages...
  //
  CFIX_LOG( L"Test string is %s", testString );
  
  //
  // ...or use plain assertions.
  //
  CFIX_ASSERT( wcslen( testString ) == 4 );
  CFIX_ASSERT_MESSAGE( testString[ 0 ] == 't', 
    L"Test string should start with a 't'" );
}
			

Clearly, TestOne should succeed. To see what happens when an assertion fails, let us write TestTwo so that it fails:

void TestTwo() 
{
  wchar_t* testString = L"test";
  
  CFIXCC_ASSERT_LESS_MESSAGE( wcslen( testString ), ( size_t ) 4, 
	L"String should be no longer than 3 chars -- but is it?" );

  CFIX_LOG( L"Will this line be executed at all?" );
}
			

	Note
	As you may have noticed, some assertions begin with CFIXCC_ and some begin with CFIX_. All CFIXCC_ assertions are for use with C++ only, while CFIX_ assertions are available to both C and C++. To add a bit of convenience, all CFIX_ assertions are also available with CFIXCC_ prefix. For instance, CFIXCC_ASSERT and CFIX_ASSERT are the same thing.

Switch back to the Explorer Window, righ-click on ExampleTest, and choose Run Test Without Debugging again. Visual Assert will cause a rebuild of the project and will start the test run. In the Run Window, we will now see the following:

Figure 2.7. Run window showing status and results of a test run

	Note
	If you have enabled the Capture Stack Traces option, TestTwo may take a while to finish -- this delay is caused by Visual Assert having to load the debug symbols for your tests. Depending on your configuration (symbol server), this may take a few moments.

Indeed, TestTwo has triggered an assertion and failed. We can see the code location that caused the assertion, as well as the expression message. If you double-click on the Failed Assertion node, you will be taken to the appropriate line in the code editor. Finally, you can expand the node and will be presented the full call stack that led to the assertion.

Figure 2.8. Show Log

There is one more thing to notice: When you click on the Show Log button, a Visual Studio output window will open:

Figure 2.9. Log Window

Note that while the message of the CFIX_LOG statement of TestOne is present, the message of TestTwo is missing: Whenever an assertion fails (such as the one in TestTwo), the method is left prematurely and all remaining statments (such as CFIX_LOG in this case) are skipped.

Now that we have a failing test, let us see how to debug it. In the Explorer Window, select the appropriate node and choose Debug Test. Once the failing assertion in TestTwo is encountered, a breakpoint will be hit:

Figure 2.10. A failed assertion

If we choosed 'Continue', the TestTwo would be left prematurely and the test run would continue. However, we would like to cause a debugger breakin and thus choose 'Break'. If you now take a closer look at the Run Window, you will see that it already shows the details for this failed assertion:

Figure 2.11. Debugging a failed assertion

Now that we have seen how to create, run, and debug tests, we can dig into some more details...