locked
Debugging native unit tests is extremely slow RRS feed

  • Question

  • I'm just starting to use Microsoft unit test framework.  I'm writing native unit tests and when I execute the test it runs in about 20 seconds.  However if I debug the unit test it runs extremely slow.  If I don't set any break points and just let it run, the test takes over 10 minutes.  This is not counting symbol loading time.  Does anyone know why it is taking so much longer?  How to make debugging quicker?


    • Moved by lake Xiao Thursday, January 28, 2016 1:48 AM Debug issue
    Thursday, January 21, 2016 8:27 PM

Answers

  • just to be sure, the Release configuration of your program will be much faster than the Debug version.  I'm not sure if you mean that the Release version takes 20 seconds and the Debug version takes 10 minutes, or if you mean that the Debug version launched normally takes 20 seconds and the Debug version launched in the debugger takes 10 minutes.  Can you clear that up first?

    Regardless...

    When you launch your program in the debugger it uses the debug heap which is much slower than the normal heap.

    If you don't mind debugging with the normal heap, you can launch your process normally (like, from the command line, for example) and then use the "attach to process" feature of your debugger to attach the debugger to the running instance of your program.  This will require you adding a special temporary feature to pause your program's execution at the very beginning, such as by printing "attach debugger now" and waiting for a key press.  This gives you a chance to attach the debugger after it starts, but before it starts running the code you wanted to debug.

    Also, 

    Just FYI: a unit test should be taking on the order of 10 to 100 milliseconds.  A 20 second test is surely not a well written unit test.  What are you testing that takes 20 seconds?!?  (Unless you're talking about a whole suite of tests...and even then...ouch!)  Also, when you debug a unit test, you should be able to just debug one specific test, not the whole suite.  A unit test should test things at a fine granularity, such as a single function.  If it depends on components that would otherwise be slow, they should be mocked.  If you rely on files or networking, they should also be mocked.   There's not really a good excuse for a unit test to take 20 seconds.

    Let me know what it is doing specifically and maybe I can help you design a better test.

    Thursday, January 28, 2016 12:41 PM

All replies

  • Hi Ed Waite,

    Thanks for your post.

    What’s version of your Visual Studio.

    Please install the latest update of the VS then try it again.

    For example: if you are using VS2013, install VS2013 Update1. If you were using VS2015, install VS2015 Update1.

    Restart your machine or close other third party program in task manager and make your PC free  then try to debug your unit test again.

    Make sure you were disabling the “Microsoft Symbol Servers”(Tools->Options->Debug->Symbols)

    Please also disable the hosting process to exclude some APIS which may affect the debugging.

    Right click your test project in Solution Explorer -> Properties->Debug->not select “Enable the Visual Studio hosting process

    By the way. Disable anti-virus or anti-spyware software.  The firewall and antivirus software can impact the assembly to load.

    Best Regards,

    Lake Xiao
    • Proposed as answer by lake Xiao Monday, January 25, 2016 8:49 AM
    Friday, January 22, 2016 6:48 AM
  • Thanks for the reply Lake.  I am on Visual Studio 2013 update 5.  For my symbols, Microsoft Symbol Server has always been checked off.  I have always limited symbol loading to only the module I am testing.  I do not see the option "Enable Visual Studio Hosing Process" in Project->Properties->Debugging.  Is this option for C++ projects?  Disabling anti-virus does not make a difference.

    Note: When I debug the actual module the performance is fine, it just when I debug the unit test that things really slow down.  Do you have other suggestions?

    Tuesday, January 26, 2016 8:59 PM
  • Hi Ed Waite,

     >> I do not see the option "Enable Visual Studio Hosing Process" in Project->Properties->Debugging.  Is this option for C++ projects?

    I did a test in my side using C# unit test project, and I have the option "Enable Visual Studio Hosing Process".

    Please take a loot at the following screenshot:

    Please try to disable this option. Then try to debug your unit test again.

    Best Regards,

    Lake Xiao

    Wednesday, January 27, 2016 2:08 AM
  • Lake...I'm trying to debug a native C++ unit test project.  I do not see that option in my Project->Properties->Debugging.  I believe that is only an option for .NET managed unit test project.
    Wednesday, January 27, 2016 5:25 PM
  • Hi Ed Waite,

    Since you issue is more related Debugging. I moved this case to Debug forum for better support.

    Thanks for your understanding.

    Best Regards,

    Lake Xiao

    Thursday, January 28, 2016 1:46 AM
  • just to be sure, the Release configuration of your program will be much faster than the Debug version.  I'm not sure if you mean that the Release version takes 20 seconds and the Debug version takes 10 minutes, or if you mean that the Debug version launched normally takes 20 seconds and the Debug version launched in the debugger takes 10 minutes.  Can you clear that up first?

    Regardless...

    When you launch your program in the debugger it uses the debug heap which is much slower than the normal heap.

    If you don't mind debugging with the normal heap, you can launch your process normally (like, from the command line, for example) and then use the "attach to process" feature of your debugger to attach the debugger to the running instance of your program.  This will require you adding a special temporary feature to pause your program's execution at the very beginning, such as by printing "attach debugger now" and waiting for a key press.  This gives you a chance to attach the debugger after it starts, but before it starts running the code you wanted to debug.

    Also, 

    Just FYI: a unit test should be taking on the order of 10 to 100 milliseconds.  A 20 second test is surely not a well written unit test.  What are you testing that takes 20 seconds?!?  (Unless you're talking about a whole suite of tests...and even then...ouch!)  Also, when you debug a unit test, you should be able to just debug one specific test, not the whole suite.  A unit test should test things at a fine granularity, such as a single function.  If it depends on components that would otherwise be slow, they should be mocked.  If you rely on files or networking, they should also be mocked.   There's not really a good excuse for a unit test to take 20 seconds.

    Let me know what it is doing specifically and maybe I can help you design a better test.

    Thursday, January 28, 2016 12:41 PM