To start writing your first test, simply stub out the service using Rhino Mocks. But don't take my word for it, take the time to experiment with test driven design and see for yourself.
#Rhino mocks code#
This will enable you to understand the intent of the code much better and find bugs at a much faster rate. You need small classes with concise methods doing one thing and only one thing. I got into these topics because I found it difficult to write a good unit test around a big ball of mud. The same would apply to my time spent with inversion of control, and learning good object oriented design in general. I would be lying if I told you that I got into interface based programming because it was one of the SOLID principles. For this example to work I'm using poor man's dependency injection via the constructor to give the program a concrete object at runtime while leaving another option for anyone testing this class. To test this class in isolation we need to have some fake object represent this dependency. Notice we have a dependency on some class that implements IUserService. Public Sub New(ByVal UserService As IUserService)įunction Edit(ByVal id As Integer, ByVal collection As FormCollection) As ActionResultĭim User As User = mUserService.GetUserById(id) The basic logic inside this method is simple so I thought it would be a good place to start. The first method we are going to test is a simple controller method that attempts to lookup a user by id and if one is found, it will call UpdateModel and save to persist the changes coming in via HTTP POST. If you are interested in learning more about TDD, mock objects, or unit testing in general be sure you subscribe to codebetter, devlicious, lostechies and infoq. I couldn't possibly cover all the concepts of mocking in a single post, let alone all the other concepts required to do unit testing in general, but I will attempt to highlight a few scenarios that I frequently come across in real projects. Just trying to be honest here, but to be clear I am yet to come up against a wall with this framework (with the exception of this - 'it would be nice to have' the ability to stub a return of IQueryable using a lambda expression).
I decided on Rhino Mocks because it was the first one that worked. This is just one of many frameworks available but if you're interested in learning more about the others available checkout this post by Roy Osherove titled 'Choosing a Mock Object Framework'. The library I will be showing in this post is Rhino Mocks, and open source mock object framework written by Ayende Rahien.
Although I strive to keep the number of dependencies low, it seems almost every unit test I write would call into another class if I didn't use a *fake / mock / stub* object instead. But in the 'real world' almost every class I work with has some type of dependency.
The class didn't depend on anything, so testing each bit of functionality was easy. This is the reason your average calculator example looked so easy. One of these new concepts was mock objects and more specifically 'how to use a mock object framework to help enable testing in isolation'.Ī mock object is simply a 'fake' object that will play the role of some dependency in a unit of code under test. When I first started learning test driven development, I came across a slew of new concepts that seemed to be missing from the simple calculator examples scattered across the blogosphere.
0 kommentar(er)
