Testing an Unmanaged Class with an Unmanaged Test Harness

To illustrate the design of a test harness, this section explains a simple class and some code that will test it. Switch to the solution view in Visual Studio by clicking the Solution tab in the tabbed window at the right or choosing View, Solution Explorer. Right-click the solution name , FirstConsole, and choose Add, Add Class. Select Generic C++ class on the left and click Open.

Writing a Simple Class

Fill in the class name as Order . (This class will represent a customer order.) The filenames will be entered for you; click Finish. The definition of the class looks like Listing 2.1, and the implementation appears in Listing 2.2. The implementation of the global operator for sending the object to an ostream such as cout is included with the actual member functions of the class, because it is a friend and has access to the private member variables .

Listing 2.1 Definition of the Order Class
 #pragma once #include <iostream> using namespace std; class Order { private:     int ordernumber;     int itemnumber;     int quantity; friend ostream& operator<<(ostream& os, const Order& order); public:     Order(void);     Order(int on, int in, int q);     ~Order(void); }; 
Listing 2.2 Implementation of the Order Class
 #include "StdAfx.h"  #include ".\order.h"  ostream& operator<<(ostream& os, const Order& order) {     os << "Order Number " << order.ordernumber << ": " << order.quantity        << " of item " << order.itemnumber << endl;     return os; } Order::Order(void) : ordernumber(-1), itemnumber(-1), quantity(0) { } Order::Order(int on, int in, int q): ordernumber(on), itemnumber(in), quantity(q) { } Order::~Order(void) { } 

Order is a simple class that holds three variables: It has two constructors and an overload of the << operator that can be used to write the three variables' values. The destructor doesn't do anything, but because the wizard generated it you might as well leave it in case you add members later that need to be cleaned up in a destructor.

Writing a Test Harness

Here is a simple main function that exercises both constructors and the << operator, and confirms that it's okay to allocate an instance on the heap with the new operator and then get rid of it with the delete operator:

 
 #include "stdafx.h"  #include "order.h"  int _tmain(int argc, _TCHAR* argv[]) {     Order blank;     cout << "Blank Order"  << endl;     cout << blank << endl;     Order filled(1,345,7);     cout << "Filled Order"  << endl;     cout << filled << endl;     Order* p = new Order();     cout << "Heap Order"  << endl;     cout << *p << endl;     delete p;     cout << "Tests complete"  << endl;     return 0; } 

The output of this test harness looks like this:

 
 Blank Order Order Number -1: 0 of item -1 Filled Order Order Number 1: 7 of item 345 Heap Order Order Number -1: 0 of item -1 Tests complete Press any key to continue 

This proves that the constructors perform as they should, that the << operator works, and that the application doesn't blow up or end abnormally when it uses instances of the Order class on either the stack or the heap. That's just what test harnesses are for. Test harnesses you write professionally might be more complex, especially ones that test several classes at once, but they should always be easy to understand and perform one purposeto test your code and prove it works.

Because FirstConsole is an unmanaged application, you can copy the .EXE file to another Windows machine and it will run there without any problem. The only library it needs is the C runtime, which is installed with Windows. If you created a more complex test harness, you would need to deploy any related COM components or DLLs along with the .EXE file, register them, and perhaps adjust the environment variables such as PATH . Large unmanaged applications can be difficult to deploy. And of course, the executable cannot be copied to a non-Windows machineit is strictly a Windows application.

Debugging an Unmanaged Console Application

You write a test harness to test your code and prove that it works. What if it doesn't? One of the most powerful tools available to a developer is the debugger, which lets you examine your code and variables while an application executes, so that you can understand why it is doing something you didn't expect.

The debugger is part of Visual Studio, and you can interact with it from the code editor. This makes Visual Studio a very productive development tool. In the code editor, click in the gray margin to the left of this line of code:

 
 Order blank; 

A red dot should appear, as in Figure 2.3, representing a breakpoint a place in the execution of your application where the debugger will pause. Choose Debug, Start, and the application will run until this breakpoint is reached. The yellow arrow in the margin, as in Figure 2.4, indicates the line of code that is about to execute.

Figure 2.3. Click in the margin to set a breakpoint, which appears as a red dot.

graphics/02fig03.gif

Figure 2.4. When the application is running, it will pause at the breakpoint.

graphics/02fig04.jpg

The Debug, Step Over menu item (look for a toolbar button and a keyboard shortcut for this command) moves the execution point to the next line of code. Step your way through the code a line at a time. Hover a variable to see its value, and if you like, step into a line of code (such as the construction of an object or the call to the << operator) to watch the called function run. You can switch to the console window where the output of the application appears to watch it being written as you move through the application. When you are debugging, the prompt "press any key to continue" does not appear at the end of the program as it does when you run without debugging.



Microsoft Visual C++. NET 2003 Kick Start
Microsoft Visual C++ .NET 2003 Kick Start
ISBN: 0672326000
EAN: 2147483647
Year: 2002
Pages: 141
Authors: Kate Gregory

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net