Contents tagged with UnitTesting
-
Using hg bisect to hunt down bugs
The “bisect” command in Mercurial (git has it too) is a great way to quickly find which version of your code introduced a bug. This post will show you how to use the bisect command along with handling a small “gotcha” I encountered while using it.
-
HOWTO: Change which “.testsettings” file Visual Stuido 2010 uses
I’m blogging this mainly for historical reasons. I just spent over 30 minutes trying to figure this out. Well, the first 10 or 15 minutes was getting code coverage enabled in Visual Studio 2010. There’s plenty of coverage on that topic since it’s not as intuitive as it could be. I’ll let Google handle that one.
-
Updates to Nino’s .hgignore files for Visual Studio
As I move more of my repositories from SVN to Mercurial, I’m constantly referring to Nino’s sample .hgignore file he provided for Visual Studio developers. I always start with his file but add a few more lines and thought I’d share them here. Start with Nino’s .hgignore file and add the following two lines at the bottom:
-
Verbosity Isn’t Always a Bad Thing
There was a message posted to the Rhino.Mocks forums yesterday about verifying a single parameter of a method that accepted 5 parameters. The code looked like this:
-
Talks Submitted for Ann Arbor Day of .NET 2010
Just submitted my session abstracts for Ann Arbor's Day of .NET 2010.
-
Unit Tests and Debug.Assert()
I recently found some code that had a couple of issues:
-
Enabling Windsor Integration in MonoRail
I recently wanted to take on old MonoRail application and update it to use Windsor for dependency injection (DI). The application stated as a sort of prototype and slowing grew into a decent sized application. There's a couple of places that I want to add some unit tests and I could really benefit from DI. So I sat down to hook Windsor into the application.
-
ASP.NET MVC + MVC Contrib + Unit Testing
One of the key benefits of the MVC (Model View Controller) pattern is a separation of concerns that leads to better testability. Microsoft recognizes this and will automatically create a separate MS Test project when creating a new ASP.NET MVC solution. While this gives you a nice head start, there's room for improvement. While actions in the MVC pattern are simply methods on a class that can easily be called by MSTest (or any unit testing framework), most web applications have interactions with supporting objects such a Request (query string, form parameters, etc…), Response (cookies, content type, headers, etc…), Session, and more. In a live environment, these objects come as a result of the HTTP request being processed by IIS. In a test environment, you're isolating just your controllers and actions and you don't have IIS and an entire HTTP pipeline.
-
Verifying collections/arrays in MS Unit Testing
If you're using Microsoft's unit testing framework that is built in to VS2008 (and some VS2005 SKU's), you're probably aware of the Assert class. You use that a lot to make assertions on properties and return values to determine if your unit test passed or failed.