You might want to mock everything as you go, or you might just want to mock where required. You may find that you start out creating stubs, then later you may find that you need to create full on mocks for some of your objects. ![]() A stub can usually be expanded into a mock. They represent slightly different approaches to testing. Rather like the difference between similes and metaphors, the difference between stubs and mocks is subtle and historical, and perhaps has more to do with the different communities and philosophies in the testing world than any major technical difference. To sum upĪ mock is a stub with an implementation, which lets us test side effects. When we call session.login, we can assert that user.lastLoggedIn has the state we expected. We could create a mock User that implements this method. If our function under test interacts with our mock object, we can verify that the mock has been interacted with as we expected.įor example, say we had a mock User object, and we wanted to verify that our session.login method worked, we might want to check that user.lastLoggedIn was set. Expect.Call (session.DoSomething).Repeat.Any () Equally if the ISession had a property named Result which was of type string we can declare the expectation as follows. MocksĪ Mock is a stub with an implementation. will fail to compile as we cannot convert from void to, we can easily fix by removing the () and using the following line. It doesn't let us verify any side effects, because the stub has no implementation. This lets us verify the behaviour of the function under test. Whats interesting to me about Rhino Mocks (and other libraries) is how the general philosophy and ideas behind the author(s) seep in. StubsĪ Stub is a tiny fake object that your test can use as a parameter to make the function call work. We might sometimes also mock global objects. We use stubs and mocks to satisfy these parameters. These functions and methods might require parameters. Generally Speaking, Unit tests call functions and methods, and then check to see if the expected behavior took place. IMPORTANT: A stub will never cause a test to fail. If you want just to pass a value that may need to act in a certain way, but isn't the focus of this test, you will use a stub. If you want to verify the behavior of the code under test, you will use a mock with the appropriate expectation, and verify that. A stub's properties will automatically behave like normal properties, and you can't set expectations on them. So, here's my best shot at some concise definitions: A normal mock object will throw an exception when a method, which has no explicit expectation defined, is called on the mock instance. You can setup expectations on it, so it would act in certain ways, but those expectations will never be verified. The difference between these three types of Rhino Mocks mocking solutions has always been a little confusing to me. A stub is an object that you use in order to pass to the code under test. I want to focus on the difference from the point of view of Rhino Mocks.Ī mock is an object that we can set expectations on, and which will verify that the expected actions have indeed occurred. You can get the actual definition of the these terms in this article: Mocks Aren't Stubs. The Arg statement let's you specify a type and tell Rhino Mocks you don't know or don't care about the value: Args.Is.Anything You can also tell Rhino Mocks you know the type and what the value should be: Args.Is.![]() I also found the answer to my question in Ayende's words: ![]() I haven't play enough with this and usually use mocks, but I wonder what are the differences between this two and when to use one or the other on Rhino Mocks.
0 Comments
Leave a Reply. |