ddl_ex5
asked on
Prohibitive build times when creating unit tests in Visual Studio 2008
We want to move to grown up automated unit testing with our existing application. Our development environment is Visual Studio 2008 (.net 3.5) so I've been investigating using the on board unit testing (we may also look at Nunit but a one-stop-shop currently makes more sense).
Our existing application suite is a 'portal' web app housing 'applications' (i.e. within the web app folder structure, we have a folder for classes, a folder for core code and a folder per set of 'application' web pages - i.e. nothing unusual, as far as I'm aware).
The functionality consists of web pages embedded into nested master pages and referencing the shared class namespaces. The site currently contains 857 code files of varying descriptions. Most file sizes are a few KB, with the biggest single file being 175KB.
I'm able to create unit tests to test the web pages and also unit tests to test classes/methods etc. but the build time every time I make the smallest of changes is SOOOO slow as to be prohibitive. There's no point in writing unit tests if its going to take ten minutes to rebuild every time I hit "run test".
Can anyone point me in the right direction for getting this overhead down? We can't seriously use the testing facility as is.
(NB if I create a clean baby website with one page and a class file and then create unit tests for this, it runs at super-speed, so our issues are clearly to do with the size/configuration of the web project)
Our existing application suite is a 'portal' web app housing 'applications' (i.e. within the web app folder structure, we have a folder for classes, a folder for core code and a folder per set of 'application' web pages - i.e. nothing unusual, as far as I'm aware).
The functionality consists of web pages embedded into nested master pages and referencing the shared class namespaces. The site currently contains 857 code files of varying descriptions. Most file sizes are a few KB, with the biggest single file being 175KB.
I'm able to create unit tests to test the web pages and also unit tests to test classes/methods etc. but the build time every time I make the smallest of changes is SOOOO slow as to be prohibitive. There's no point in writing unit tests if its going to take ten minutes to rebuild every time I hit "run test".
Can anyone point me in the right direction for getting this overhead down? We can't seriously use the testing facility as is.
(NB if I create a clean baby website with one page and a class file and then create unit tests for this, it runs at super-speed, so our issues are clearly to do with the size/configuration of the web project)
ASKER
I'm running VS2008 inside a Parallels 3 XP virtualisation on a Mac Pro. I've upped my resources in the VM so that it should be plenty powerful enough. I can try further tuning it.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hi giltjr,
I'm was running on 1.5GB RAM on the VM, with 3 of my 4 processors (2 x dual core xeon at 2GHz) allocated. However, I'm going to try with the numbers you suggested this afternoon.
However, the problem is not confined to my machine. Two colleagues in my room are both running on core 2 quad native 32 bit XP machines running at 2.66GHz with 3.48GB available and they suffer exactly the same issues when attempting to unit test the project described in the opening question.
I'll let you know how I get on with improved spec on my machine though.
I'm was running on 1.5GB RAM on the VM, with 3 of my 4 processors (2 x dual core xeon at 2GHz) allocated. However, I'm going to try with the numbers you suggested this afternoon.
However, the problem is not confined to my machine. Two colleagues in my room are both running on core 2 quad native 32 bit XP machines running at 2.66GHz with 3.48GB available and they suffer exactly the same issues when attempting to unit test the project described in the opening question.
I'll let you know how I get on with improved spec on my machine though.
O.K. When running the unit test start task manager and see if CPU or RAM is maxed out. Make sure that task manager is configured to show each CPU.
Now it is possible that the unit test software may not be multi-tasking or multi-threaded which means it might be using just 1 core.
Now it is possible that the unit test software may not be multi-tasking or multi-threaded which means it might be using just 1 core.
ASKER
I made a one line change to a unit test.
I hit 'run' and VS goes off to build the test.
It then runs the test.
All 3 allocated processors appear to be being used 'about equally' when I view activity in Task Manager and the highest peak is briefly at around 57%. PF Usage doesn't exceed 600MB at any time.
However, the build and run process took around 5 minutes. Ouch.
I hit 'run' and VS goes off to build the test.
It then runs the test.
All 3 allocated processors appear to be being used 'about equally' when I view activity in Task Manager and the highest peak is briefly at around 57%. PF Usage doesn't exceed 600MB at any time.
However, the build and run process took around 5 minutes. Ouch.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Comments explain the probable issue although they don't solve the problem, hence the grade awarded.
Thanks for the points. As a solution there are three options:
1) If possible see if there is a "enable multi-threading" option, or an option to increase the number of threads.
2) Get a faster CPU.
3) Live with it. :)
One of the problem in the computer world that some people don't understand is sometimes more CPU's don't help. If you have a environment that has a lot of tasks that must do work at the same time (which includes multi-threading) then more slower processors typically are better. However if you have an enviroment where you have a few very CPU intensive tasks, then fewer faster processors are better.
Of course more faster processors always help, but sometimes are too expensive. For the typical desktop, including developers desktops, fewer faster processors are better. For servers, you really have to know your workload.
1) If possible see if there is a "enable multi-threading" option, or an option to increase the number of threads.
2) Get a faster CPU.
3) Live with it. :)
One of the problem in the computer world that some people don't understand is sometimes more CPU's don't help. If you have a environment that has a lot of tasks that must do work at the same time (which includes multi-threading) then more slower processors typically are better. However if you have an enviroment where you have a few very CPU intensive tasks, then fewer faster processors are better.
Of course more faster processors always help, but sometimes are too expensive. For the typical desktop, including developers desktops, fewer faster processors are better. For servers, you really have to know your workload.
Which processor, how many processor, speed of processors?
How much RAM?
When your are doing the testing processing how much RAM is in use? Typically these processes are VERY memory intensive. If you have, say 1 GB of ram and it is using 2GB's that means you are doing a LOT of paging, which will add a lot of I/O overhead.