A day in the life of...

[TestMethod] public void Meh() { var mockFileSystem = MockRepository.GenerateMock<IFileSystemService>(); mockFileSystem.Stub(fs => fs.CreateFileStream(null, FileMode.Append, FileAccess.Write, FileShare.None)) .IgnoreArguments() .Return(new MemoryStream()); var result1 = mockFileSystem.CreateFileStream(null, FileMode.Append, FileAccess.Write, FileShare.None); var result2 = mockFileSystem.CreateFileStream(null, FileMode.Append, FileAccess.Write, FileShare.None); Assert.AreNotSame(result1, result2); } This test case shows a problem I was having. The return value of the stubbed CreateFileStream method isn't calculated each time it is called, it is calculated once at the point you defined the stub method and then returned for every subsequent call. The problem with this is that my real test needed to call CreateFileStream twice and get two different streams, the test was failing because the method being tested disposes of the stream it uses; this was resulti

When I run my unit tests in my project I am seeing a result "Not executed" for every one. I have restarted my computer so I doubt this is some kind of hung process issue. Google has revealed nothing that is not related to load balancing, and I am not load balancing! Solved In order to determine the error you have to do this Open the Visual Studio command prompt Change to the directory where the binary output of your test project is. Type mstest /testcontainer:The.Name.Of.Your.Test.Assembly.dll At the bottom of the output you will see the following text Run has the following issue(s): In my case it was the following: Failed to queue test run 'Peter Morris@PETERMORRIS-PC 2009-02-09 10:00:37': Test Run deployment issue: The location of the file or directory 'C:\SomePath\SomeProject.Tests\bin\Debug\Rhino.Mocks.dll' is not trusted. Now if VS had told me this in the IDE I could have fixed it in minutes! All you have to do is open Windows Explorer and

I am lazy.  I don't mean that I don't work, I mean that I like to get my work done with as little effort as possible.  Writing tests before my code used to look like too much extra work, but I've realised just how much time they actually save me. When you make a small change to something it's very easy to think to yourself "That's such a small change, I can't see how it can possibly fail", what I have also realised is this really means "Despite this being a small change, it will fail and I can't possibly see how". I recently observed a change to some code that introduced a simple if statement, and all existing tests passed.  The problem is that the existing tests only checked the expected behaviour worked (which it still did), but by introducing the "if" statement (and an additional parameter on the method) the developer had changed the expected behaviour under certain circumstances .  Thinking it was so simple it couldn't p

I was just reading through the VBUG events list when I came across an event entitled "Domain driven design approach, using unit testing". "Sounds interesting!" I thought to myself, I hope I can make it! As I started to read it I thought it looked familiar. At that point I realised it was me doing the talk! So hopefully I will be able to make it :-) The posting is here . If you come along make sure you say "Hello".

I have a method that looks something like this public void DoSomething(SomeClass someInstance, User user) {   var persistence = someInstance.AsIObject.GetEcoService<IPersistenceService>();   persistence.Unload(someInstance.AsIObject());      if (someInstance.CurrentUser != null)     throw new ..........;   someInstance.CurrentUser = user;   persistence.UpdateDatabase(someInstance); } This unloads the local cache before ensuring someInstance.CurrentUser == null, it then sets someInstance.CurrentUser and updates the DB. The unit test I wanted would check what happens when two users try to perform this at the same time. What I wanted was User A: Unload User B: Unload User A: Check == null, it is User B: Check == null, it is User A: Change + update DB User B: Change + update DB + experience a lock exception What I didn't want was User A: Unload User B: Unload User A: Check == null, it is User A: Change + update DB User B: Check == null, it isn't To achieve two things runnin

Following on from my previous post about using(Tricks) here is an example which makes writing test cases easier rather than just for making your code nicely formatted. Take a look at the following test which ensures Article.Publish sets the PublishedDate correctly: [TestMethod] public void PublishedDateIsSet() {   //Create the EcoSpace, set its PMapper to a memory mapper   var ecoSpace = TestHelper.EcoSpace.Create();   //Creat an article   var article = new Article(ecoSpace);   //Create our Rhino Mocks repository   var mocks = new MockRepository();   //Mock the date/time to give us a predictable value   var mockDateTimeService = mocks.StrictMock<IDateTimeService>();   ecoSpace.RegisterEcoService(typeof(IDateTimeService), mockDateTimeService);   //Get a date/time to return from the mock DateTimeService   var now = DateTime.Now;   using (mocks.Record())   {     //When asked, return the value we recorded earlier     Expect.Call(mockDateTimeService.Now).Return(now);   }   //Check mo

I have decided that mocking IEcoServiceProvider is not the way to go. Your controller will use the mocked provider during testing but   You don’t want to have to mock every service the provider may return, it’s a lot of work!   You don’t want your controller using a mocked service, and then the EcoSpace using the real one! At first I was mocking every possible service request. IUndoService, IPersistenceService, IOclService, etc. I get bored typing them out in this blog, so doing it in tests was really annoying me. I decided I would instead only mock the service in question. So if I were ensuring that an action wont save an object with broken constraints I would mock GetEcoService<IConstraintProvider> and ensure that I always got a broken constraint. The problem was that the test to ensure I can save a valid object would then invoke the IPersistenceService.UpdateDatabaseWithList method. In my EcoSpace I have decorated my persistence service so that it checks every object i

Here are my latest revelations :-) 01 Instead of having to mock IEcoServiceProvider and IOclPsService in order to avoid DB access simply use PersistenceMapperMemory. This way I can create the objects I want, UpdateDatabase, and then run my tests. It’s much easier to read, and more importantly less typing. 02 My page controllers no longer use an EcoSpace. Instead the code always uses a ServiceProvider property of type IEcoServiceProvider. When I want to test my controller I create an instance and set its ServiceProvider property. Now whenever the controller needs to do anything it will go through the ServiceProvider I specified. This is beneficial for a number of reasons. Firstly it means that I can create an EcoSpace in my test and set its PersistenceMapper to PersistenceMapperMemory before activating it. Secondly I can also opt to pass a mocked IEcoServiceProvider which either returns the real service requested or returns a mocked one. An example of this is that I validate my