Well, if you must have reasons, then Typemock re-posted an excellent list of them:
http://www.typemock.com/blog/2011/11/28/10-reasons-to-write-unit-tests/
Or, check out this post at its original location:
http://annafilina.com/blog/10-reasons-to-write-unit-tests/
Enjoy,
NCover Support
Courtesy of Steve Fenton, here's some great information on using MSBuild scripts to exclude code that you don't want in your coverage reports.
Thanks, Steve!
http://www.stevefenton.co.uk/Content/Blog/Date/201105/Blog/Using-NCover-Exclusions-With-MSBuild/
It's another Whizz Bang Webinar!
Date: Thursday, April 21, 2011
Time: 1:00 pm EDT, Noon CDT, 11:00 am PDT
Development organizations are schizophrenic. We talk about the need to reduce risk in our releases, but fail to take action to make that happen. Despite saying that quality is important, we fail many times to measure the quality of our code or the progress of our testing efforts. Instead, each new release comes with the fear of regressions, productions delays, and expensive production downtime – a costly organizational lifecycle.
Simply measuring test coverage and code complexity can change that cycle. The right metrics can help identify the riskiest code – resulting in more effective testing and refactoring efforts. Release risk can be reduced by ensuring new code has been adequately tested and understanding how old code was effected. Data-driven feedback to developers and testers creates a positive feedback loop: improvements in quality free more time for further improvements, reducing the otherwise fatal buildup of technical debt.
Development, QA and Release Managers interested in improving the reliability of releases should join us in this webinar to learn:
Dan Waldschmidt helps savvy software teams design data-driven testing architectures. Using NCover to pinpoint code risk throughout the development lifecycle, Dan builds custom solutions that give .NET teams easy access to answers.
An internationally recognized expert on Continuous Integration, Jeffrey Fredrick is an 19-year veteran of the software industry who has performed and managed virtually every role in the software development lifecycle. An early adopter of XP and Agile software development, the top committer for CruiseControl, and a 10-year veteran of leading Continuous Integration efforts, Jeffrey has consistently been at the forefront of the industry. He currently indulges his passion for improving how software is made as a Technical Evangelist at Urbancode, as the organizer of the Silicon Valley Agile Meetup, and as the co-organizer of the Continuous Integration and Testing Conference (CITCON).
We look forward to seeing you at the event.
The wizards at NCover have done it again.
Introducing ServiceWatcher…have you ever wanted to cover multiple services during a test but didn’t want to have to start / stop them all manually? If you’re in an environment that can’t tolerate service interruption, you’ll want to check out this simple and FREE solution.
ServiceWatcher lets you cover any service(s) multiple times on a test run. Start and stop services and gain coverage data on every iteration without having to restart tests. ServiceWatcher is a .NET application that utilizes configurable bat scripts for coverage runs. The scripts are completely reconfigurable so that your team can personalize them for its unique build / test process. Just follow along in the comments and you’ll be testing like a pro in no time.
Download: http://downloads.ncover.com/ncover.servicewatcher.zip
Here are some instructions for getting started.
To start coverage, browse to and run the NCover Core Services - cover services.cmd. This will open a command prompt that will start all the services under the service watcher and NCover coverage.
The following is a description of each of the files inside the .ZIP file for download.
This executable is the core of the coverage process, restarting coverage on the desired services. NCover collects coverage by monitoring the service. Whenever NCover exits for a given service, the watcher will restart NCover on that service. When the service stops, NCover writes the coverage and trend data.
To cycle collection of data on services then the service must be stopped. NCover will collect coverage data. And then the watcher will restart NCover when the last NCover process completes for that service. Source code for this utility is provided without expressed or implied warranty. Use and modify as needed for your purposes.
This batch file starts NCover coverage for all of the services and outputs the data and logs to c:\ncoverdata location. This path can be modified to a location of your preference. It is implemented with a single command that is reused for all services.
The command is located at the :coverService label in the batch file. Add additional NCover options here. The coverage for each service is collected to a separate nccov file. The trend data is collected to a shared trend file. If you need to specify a project name or other NCover options you can do so in this command.
Be sure to quote the values so that odd filenames don't break the command line (e.g., //x "%COVERAGE_PATH%\%2_[time].nccov"). Variable %1 is the service name in windows. %2 is the file name stub you want to use for that service. There is a second coverage command in this section, which has been commented out.
A shortcut to stop all the services under coverage. This script is helpful when you just want to stop all coverage.
A shortcut to kill all the ncover.servicewatcher.exe processes that are currently running. This script is needed to turn off coverage once it has begun. Otherwise as each service stops the watcher will just restart it.
Send us some feedback when you're done.
Not sure you understand all the commotion around technical debt?
Michael Norton (a.k.a. @DoconDev on Twitter) put together a funny and insightful presentation that is perfect for making sense of code quality.
Make sure you leave some notes for Michael or download this to share with your team...
It's a great way to jump-start a development discussion.