Skip to main content

Rhino Mocks Caveat: Expect.Call / Setup.For / Stubs and Defaults

I got bitten by not knowing some Rhino Mocks API details today. I had some tests written a certain way which were passing and some others written the same way which were failing. (Code can be found here.) In the case of the successful tests, Rhino Mocks appeared to be properly returning a mock object when a property was called on another mock, and in the case of the failing tests it was returning nulls for the property on a mocked object. There didn’t appear to be any difference in the way I needed to declare and setup the mocks used in the test, but there was a subtle one: the code that passed the tests only accessed the property once, whereas the code that failed accessed it multiple times. Because of the way I set up my mocks, a mock was returned for the property the first time it was accessed only.

If you use Expect.Call(…).Return(someObject), by default the method/property will only return the specified object once. If you use a stub or SetupResult.For(…).Return(someObject), by default the method/property will return the specified object as many times as it is called.

Since I prefer the consistency of using Expect.Call for any kind of expectation (and I think it reads better), I used Expect.Call(…).Return(someObject).Repeat.Any() to allow the property to return what I wanted every time it was called.

File this under the importance of defaults.

Labels:

Comments

Post a Comment

Popular posts from this blog

Migrating Hg Repos with hg-fast-export and Windows Subsystem for Linux

Introduction I prefer Mercurial (hg) to git . I don’t really have any reason for this preference - they both do the same thing, and the user experience for 90% of the use cases is the same. It probably comes from the conditions of the DVCS landscape when I started using these systems. Some of this may have been perception only, but it looked like this: GitHub didn’t have free private repos BitBucket did have free private repos BitBucket was very hg-friendly Joel Spolsky had an amazing tutorial that served as both a how-to for hg as well as a general intro to DVCS hg was much more Windows-friendly than git Since hg was written in python, I felt like extending it would be easier than doing so for git if I ever needed to (admittedly, this is a pretty ridiculous reason) hg felt like a more unified, “coherent” system than the very linux-y feeling git and its extensions (also pretty ridiculous) Where they differed, I liked the verbs hg used better than git’s counterparts ...
Post a Comment
Read more

Enabling Globalization Invariant Mode for .NET Core App on Raspberry Pi Running LibreElec

I had an app I wanted to run on my Raspberry Pi 3 running LibreElec . In LibreElec you can install the dotnet core 2.2 runtime as an addon, and in Visual Studio you can compile for ARM processors with ‘Target Runtime’ set to ‘linux-arm’ in the publish profile. So, I published to a folder from VS using that profile, and I copied the output over to my RPi which had the dotnet runtime installed. I did a simple dotnet Whatever.dll to run the app (actually in this case, it was /storage/.kodi/addons/tools.dotnet-runtime/bin/dotnet Whatever.dll because of the way the addon is installed) and was met with this error: FailFast: Couldn't find a valid ICU package installed on the system. Set the configuration flag System.Globalization.Invariant to true if you want to run with no globalization support. at System.Environment.FailFast(System.String) at System.Globalization.GlobalizationMode.GetGlobalizationInvariantMode() at System.Globalization.GlobalizationMode..cctor() at Syste...
Post a Comment
Read more

Stubbing Static Methods with PostSharp

TypeMock uses the Profiler API to allow mocking, stubbing, etc. of classes used by code under test. It has the ability to handle sealed classes, static classes, non-virtual methods, and other troublesome-yet-oft-encountered scenarios in the world of unit testing. Other frameworks rely on proxies to intercept method calls, limiting them to be able to only fake virtual, abstract, and interface members. They also rely on dependecy injection to place the proxies as the concrete implementation of calls to the abstracted interface members. Anyone working with a legacy codebase is bound to run into static method calls (especially in the data access layer), dependencies on concrete types with non-virtual methods, and sealed class dependencies (HttpContext anyone?). The only way to unit test this without refactoring is with TypeMock. I've never used TypeMock, and I'm sure it's a great product, but it's not free. I decided to spike some code to see if I could solve the prob...
6 comments
Read more