views:

8076

answers:

10

I have a collection of boost unit tests I want to run as a console application.

When I'm working on the project and I run the tests I would like to be able to debug the tests and I would like to have the console stay open after the tests run.

I see that if I run in release mode the console window stays up after the program exits, but in debug mode this is not the case.

I do not want to add 'system("pause");' or any other hacks like reading a character to my program. I just want to make Visual Studio pause after running the tests with debugging like it would if I were running in release mode. I would also like it if the output of tests were captured in one of Visual Studio's output windows but that also seems to be harder than it should be.

How can I do this?

Thanks!

+1  A: 

It would actually be more effort, but you could just build in VS.Net, run it from the regular command line (cmd.exe), and then attach to the process after it starts running. This is probably not the solution you are looking for however.

Kibbee
The reason I'm not looking for this solution is because it's a bit heavy handed. I want my tests to run with debugging assertions enabled, so I do want to run in debug mode but I also want to see the test suite output.
Jason Dagit
A: 

What about just using a logging library, like log4net, and have it log to a file appender?

Bob King
Well, this is C++ but I get your point. I'm using the BOOST unit testing stuff. I could log things in the test that way, but I have no idea how to make the boost test framework log to somewhere special.
Jason Dagit
A: 

You could also setup your executable as an external tool, and mark the tool for Use output window. That way the output of the tool will be visible within Visual Studio itself, not a separate window.

Andrew
+1  A: 

Set a breakpoint on the last line of code.

Kevin Timmerman
+8  A: 

boost test offers the following usage recommendations for visual studio that would enable you to run the unit tests automatically at the end of compilation and capture the output into the build window.

the nice side effect of this trick is it enable you to treat test failures as compilation errors. "...you could jump through these errors using usual keyboard shortcuts/mouse clicks you use for compilation error analysis..."

Raz
+1  A: 

Why not use the system("pause") hack?

If it's because you don't want the program to prompt when it's not being debugged, there's a way around that. This works for me:

void pause ()   {
system ("pause");
}
int main (int argc, char ** argv)   {
    // If "launched", then don't let the console close at the end until the
    // user has seen the report.
    // (See the MSDN ConGUI sample code)
    //
    do {
     HANDLE hConsoleOutput = ::GetStdHandle (STD_OUTPUT_HANDLE);
     if (INVALID_HANDLE_VALUE == hConsoleOutput) break;
        CONSOLE_SCREEN_BUFFER_INFO csbi;
     if (0 == ::GetConsoleScreenBufferInfo (hConsoleOutput, &csbi)) break;
     if (0 != csbi.dwCursorPosition.X) break;
     if (0 != csbi.dwCursorPosition.Y) break;
        if (csbi.dwSize.X <= 0) break;
     if (csbi.dwSize.Y <= 0) break;
     atexit (pause);
     } while (0);

I just paste this code into each new console app I'm writing. If the program is being run from a command window, the cursor position won't be <0,0> and it won't call atexit(). If it has been launched from you debugger (any debugger) the console cursor position will be <0,0> and the atexit() call will be executed.

I got the idea from a sample program that used to be in the MSDN library, but I think it's been deleted.

Edit addition: The Microsft VS implementation of the system() routine requires the COMSPEC environment variable to identify the command line interpreter. If this environment variable gets messed up -- for example, if you've got a problem in the Visual Studio project's debugging properties so that the environment variables aren't properly passed down when the program is launched -- then it will just fail silently.

Die in Sente
+14  A: 

Try to run the app with the Ctrl+F5 combination.

Cichy
Thanks for this... very handy.
Saul Dolgin
A: 

I start the app with F11 and get a breakpoint somewhere in unit_test_main.ipp (can be assembly code). I use shift-f11 (Step out) to run the unit test and get the next assembly instruction in the CRT (normally in mainCRTStartup()). I use F9 to set a breakpoint at that instruction.

On the next invocation, I can start the app with F5 and the app will break after running the tests, therefore giving me a chance to peek at the console window

Amanjit Gill
A: 

Do a readline at the end, (Its the "forma cochina", like we say in Colombia, but it works)

static void Main(string[] args)
{
            .
            .
            .
            String temp = Console.ReadLine();
}
Daniel G. R.
A: 

take a input at the last of program........

Rahul