Community Blogs

-- UPDATE See text in red below -- Ok, I am in NO way trying to say that this is either Rhino's issue or MSTest. I am simply blogging this with the intent that someone can shed some insight as to what may be going on. Although, since I know that the AAA logic of Rhino works with the EXACT same code under NUnit i have to believe it has something to do with the MSTest works. So here is my propblem: I have a test where i want to mock out and set an expectation on a repository. When I tried the code via the AAA syntax my expectation would only return a null. When I changed to use Record/Playback everything worked well. Odd. Here is the syntax for AAA (non-working) var mockRepository = new MockRepository(); var mockStatusCheckRepository = mockRepository...

I actually meant to say in my last post that I had investigated the API options for FriendFeed and they have a C# wrapper already available here . It's packaged up in a single download with its Python and PHP counterparts. Unfortunately, it has compilation errors. I fixed the errors and then I let ReSharper (R#) have its way with it [ R#: Ctrl+Alt+Shift+F]. Yes, I do understand that the Code Cleanup feature of R# can be a nuclear bomb of churn for diffing your source, but egads I do love it so. I also broke out the FriendFeed classes into separate files [ R#: F6] . Hmm, I just decided that I'll notate R# and VisualStudio keyboard shortcuts like this [app:shortcut]. Is there already a convention for that out there? I also decided to keep...

In a rather indirect way, I was inspired by a commenter on one of Scott Hanselman's posts to begin a series that walks through building a WPF application from start to finish. We did this for four different applications in our book , but those where targeted to demonstrate particular facets of WPF whereas in these (yet unwritten) posts I'd like to focus more on "this is how I build my WPF apps". Not to say that my way is the *right way*, but so that we might learn together. In the spirit of the aforementioned post, I'm bound to make mistakes, so please (gently) correct me when you think you see one. What to build? You might not have noticed, but there's quite a bit of .NET chatter in twit-space . There are already lots...

TDD and Hard-To-Test Areas I wanted to talk about the issues that people get when they begin working with TDD, the same issues that tend to make them abandon TDD after an initial experiment. Those are the 'hard-to-test' areas, the things production code needs to do, that those presentations and introductory books just don't seem to explain well. In this post we will start with a quick review of TDD, and then get into why people fail when they start trying to use it. Next time around we will look more closely at solutions. Review Clean Code Now TDD is an approach to development in which we write our tests, before writing production code. The benefit of this are: Tests help us improve quality: Tests give us prompt feedback. We receive...

In this tip, I demonstrate how you can create unit tests for the routes in your ASP.NET MVC applications. I show how to test whether a URL is being mapped to the right controller, controller action, and action parameters. If you are being virtuous about test-driven development when building an ASP.NET MVC application, then you should write unit tests for everything. Write the unit test first then write the code that satisfies the test. Repeat, repeat, repeat, ad nauseam. Routes are a very important...( read more ) Read More...

In this tip, I show you how to test ASP.NET intrinsics when building unit tests for an ASP.NET MVC application. I show you how to create a standard set of fake objects that enables you to fake the current user, the current user roles, the request parameters, session state, and cookies. An ASP.NET MVC application is infinitely more testable than an ASP.NET Web Forms application. Every feature of ASP.NET MVC was designed with testability in mind. However, there are still certain aspects of an ASP.NET...( read more ) Read More...

The purpose of this blog entry is to provide you with an introduction to the xUnit.net unit testing framework, the newest unit testing framework for the .NET framework. I want to demonstrate how you can use the xUnit.net framework when practicing test-driven development. In particular, I focus on using xUnit.net when building an ASP.NET MVC application. This blog entry is divided into three parts. In the first part, I explain how to download and reference the xUnit.net framework when building an...( read more ) Read More...

I finally got around to downloading and playing with the forthcoming release of Rhino Mocks v3.5 (more info here from Ayende). The major changes to this version is that the syntax has been revamped to allow for the new language features in .Net 3.5.  Another big change with this release is that the dreaded Record-Replay semantics have been depreciated (although I have to admit that they never bothered me). What I thought I would do today is do a little comparison with Rhino 3.5 against Rhino 3.4 (and older) as well as compare it to Moq as this mocking framework has been getting a lot of buzz lately. The example below is a pretty straight forward example where I need to mock out my data repository for a test and I want to ensure that the...

In this post, I provide an introduction to Moq which is the newest of the Mock Object Frameworks. Moq is promoted by its creators as easier to learn and use than other Mock Object Frameworks such as Rhino Mocks and TypeMock Isolator. Moq takes advantage of recent VB.NET and C# language features such as lambdas and generics. When creating mock objects with Moq, you use lambda expressions to represent the methods and properties that you want to mock. The emphasis on lambdas enables Moq to provide a very clean syntax for representing expectations, parameter constraints, and return values. According to the authors of Moq, you can pronounce “Moq” either like “Mock-You” or like “Mock”. The name “Moq”...

Ian Cooper brought up an interesting point on the altdotnet mailing list recently, around the language used to describe Mocks, or more accurately his preference for the term Test Double over my use of the generic term Mock. In most areas of development I can often be considered a language perfectionist, for example calling something a Unit Test when it is *clearly* an Integration Test drives me nuts - but when it comes to Mocks, Stubs, Fakes, Spys, or the rather more generic Test Doubles ... I just can't get passionate about the language. This all started a while ago, when people started using the term mock, but really it wasn't a mock - or more often they used the term mock when referring to what many mock frameworks call a Strict Mock...