Running the test
Before we can run the test in the debugger for the first time, we have to make some adaptions to the project configuration . Open the project's property page and navigate to the 'Debugging' node. There, add 'cfix32.exe' (or 'cfix64.exe' for the x64 configuration) as Command. Note: do not omit the .exe suffix -- otherwise running without debugger will not work.
|Do not forget the quotes around the path.|
|When using C++, you shoud use the compiler switch /EHa rather than /EHs. cfix internally uses SEH and using /EHa ensures that your destructors are called properly in case a test case is aborted.|
It is strongly recommended to set the Working Directory to $(OutDir) and to use this directory as a conmmon output directory for both your test DLL (i.e. the DLL containing your test cases) and for any (non-system) DLLs referenced by this test DLL. This will make sure that all DLLs will be able to be loaded properly.
Please consult the MSDN documentation for details and background information on the Dynamic-Link Library Search Order.
These adjustments having been done, we can run the test by hitting F5. After a few moments, the following assertion box should appear, notifying us that TestTwo, as anticipated, has triggered a failed assertion:
If you choose 'Break' the debugger will break in and point to the line containing the affected assertion. Meanwhile, the output window will have shown the following output:
[Log] VsSample.ExampleTest.TestOne Test string is test [Success] VsSample.ExampleTest.TestOne [Failure] VsSample.ExampleTest.TestTwo test.cpp(35): ExampleTest::TestTwo Expression: String should be no longer than 3 chars -- but is it?:  <  (Expression: wcslen( testString ) < ( size_t ) 4) Last Error: 0 (The operation completed successfully. )
Aha, the comparison has failed because 4 < 4 does not hold.
If you now continue execution by pressing F5 again, note that the routine will be left prematurely -- the CFIX_LOG statement will not be executed! With the last assertion having failed, cfix assumes that it is futile to resume the test -- and therefore aborts it.
But what happens when we instead choose 'Continue' in the assertion message box? The failure will be printed to the output window, yet execution will be resumed as normal. That is, the log statement will be executed this time.
Now that we know how cfix behaves when run in the debugger, let us run it without debugger attached. Press Ctrl+F5 and let it run. Again, after a few moments, the assertion will fail -- but rather than issuing a breakpoint, cfix will print the following output to the console:
[Log] VsSample.ExampleTest.TestOne Test string is test [Success] VsSample.ExampleTest.TestOne [Failure] VsSample.ExampleTest.TestTwo test.cpp(35): ExampleTest::TestTwo Expression: String should be no longer than 3 chars -- but is it?:  <  (Expression: wcslen( testString ) < ( size_t ) 4) Last Error: 0 (The operation completed successfully. ) cfix!CfixpCaptureStackTrace +0x40 cfix!CfixPeReportFailedAssertion +0xd2 VsSample!cfixcc::Assertion<cfixcc::Less>::Fail<unsigned int> +0x215 VsSample!cfixcc::Assertion<cfixcc::Less>::Relate<unsigned int> +0x60 VsSample!ExampleTest::TestTwo +0xdb (test.cpp:34) VsSample!cfixcc::InvokeTestMethod<ExampleTest,&ExampleTest::TestTwo> +0x3a cfix!CfixsRunTestRoutine +0x33 cfix!CfixsRunTestCaseMethod +0x27 cfix!CfixsRunTestCase +0x25 cfix!CfixsRunTsexecActionMethod +0xfb cfix!CfixsRunSequenceAction +0x122 cfix32!CfixrunpRunFixtures +0x90 cfix32!CfixrunsMainWorker +0x3f cfix32!CfixrunMain +0x1b9 cfix32!wmain +0x80