.NET Mock Object Framework Recommendations? [modified]
-
Oh, is this a new fad panacea, like "Strongly Ruthless Programming"? I'm not sure that mocking your objects regulary will in any way improve the code. Still, if I were SRP Stan, I could see the benefit: bad code will evolve because it hates being teased.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!|FoldWithUs! | sighistI'm completely new to mocking but I thought I should at least look into it to see what all the fuss is about.
Kevin
-
RhinoMocks rocks - easy to use, strongly typed, elegant API. I'll be using that at least until CPian and Microsoftie Jonathan De Halleux's[^] Pex[^] is released, which has a custom mocking framework to work with Pex's auto generation of tests and mocks.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Triumph over evil: 40th Anniversary of the 6 Day War (audio) The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
Judah Himango wrote:
until CPian and Microsoftie Jonathan De Halleux's[^] Pex[^] is released
Now, that's quite an ambitious project! Just imagine Pex to be available and robust. :drool:
-- Oliver
-
A dnrTV show on design patterns suggests that the .NET market leaders are RhinoMocks and TypeMock in that order. What do others use, if any at all? The general consensus seems to be that RhinoMocks is the one to go for. I've just started playing with it.
Last modified: after originally posted -- Added that I've opted for RhinoMocks
Kevin
what is "mocking"? -- modified at 13:36 Wednesday 13th June, 2007 Well, I googled it, and it appears as if this doubles the developers workload. Not only do you have to develop the real code, but you have to develop a mock object as well? What a pain in the ass....
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
what is "mocking"? -- modified at 13:36 Wednesday 13th June, 2007 Well, I googled it, and it appears as if this doubles the developers workload. Not only do you have to develop the real code, but you have to develop a mock object as well? What a pain in the ass....
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
what is "mocking"? -- modified at 13:36 Wednesday 13th June, 2007 Well, I googled it, and it appears as if this doubles the developers workload. Not only do you have to develop the real code, but you have to develop a mock object as well? What a pain in the ass....
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001John Simmons / outlaw programmer wrote:
you have to develop a mock object as well? What a pain in the ass....
No, the mock framework will do that for you. The short answer of what mocks are for is, they are fake objects you put in place of real dependencies. This is useful in unit testing where you probably don't want, for example, a real database sitting there while you're testing your presentation logic. So, instead of a real database, you fake it by injecting a mock object that looks and feels like the real thing (your code doesn't know the difference), but in reality is a fake. You don't actually code up a mock object. You tell a mock framework to create one for you:
MyFakeDatabase db = mockFramework.Mock<MyFakeDatabase>();
You can then use this fake/mock database in place of a real one, and use that in your unit tests. Your unit tests can also verify your code deals with the database correctly by verifying you call certain methods on your objects. For example, if you've got a program that saves data to the database when the user clicks the "Save" button on your form, it'd be difficult to write unit tests to verify your program is actually doing this because
- You don't actually want to create a button and simulate clicking it all inside the unit test; that'd be painful.
- You don't actually want to connect to a remote database, initialize the connection, and perform some SQL, all inside the unit test; that'd slow down your unit tests, and would also cause side effects.
Really, you just want to test your logic: it should respond to the Save button being clicked and then save the data to SQL. You could do this by injecting a fake/mock button and injecting a fake/mock database. Now you can write a unit test like this:
[Test]
void ClickingTheSaveButtonShouldSaveDataToDatabase()
{
// I'm expecting the fakeDatabase.SaveNewName method to be called.
mockFramework.Expect(myFakeDatabase.SaveNewName("theNewName"));// Simulate a click.
myFakeButton.Click();// Make sure our expectations happened.
mockFramework.Verify();
}Of course, this looks different for C++ frameworks, but the idea is the same. And it applies to all kinds of dependencies: databases, sockets, and GUIs are obvious ones. But you can fake everything, making your unit tests very concise; testing only the pieces you're interested in testing. Without mocks, unit testing would be very difficult and even impossible in
-
what is "mocking"? -- modified at 13:36 Wednesday 13th June, 2007 Well, I googled it, and it appears as if this doubles the developers workload. Not only do you have to develop the real code, but you have to develop a mock object as well? What a pain in the ass....
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001Its not new (providing a fake "library" that generates known responses to enable one to test code at a higher level was something I was taught over 20 years ago) and its therefore not a fad - and it certainly shouldn't "double" the developer's workload - although it does, like all testing, add to the up front effort (which should be more than recovered later on). Is testing a pain? Yes...
-
I'm completely new to mocking but I thought I should at least look into it to see what all the fuss is about.
Kevin
Kevin McFarlane wrote:
I'm completely new to mocking
Check out the Soapbox. There are some world-class experts in mocking over there.
:josh: My WPF Blog[^] FYI - Bob is a scarecrow who keeps Chuck Norris away from CodeProject.
-
John Simmons / outlaw programmer wrote:
you have to develop a mock object as well? What a pain in the ass....
No, the mock framework will do that for you. The short answer of what mocks are for is, they are fake objects you put in place of real dependencies. This is useful in unit testing where you probably don't want, for example, a real database sitting there while you're testing your presentation logic. So, instead of a real database, you fake it by injecting a mock object that looks and feels like the real thing (your code doesn't know the difference), but in reality is a fake. You don't actually code up a mock object. You tell a mock framework to create one for you:
MyFakeDatabase db = mockFramework.Mock<MyFakeDatabase>();
You can then use this fake/mock database in place of a real one, and use that in your unit tests. Your unit tests can also verify your code deals with the database correctly by verifying you call certain methods on your objects. For example, if you've got a program that saves data to the database when the user clicks the "Save" button on your form, it'd be difficult to write unit tests to verify your program is actually doing this because
- You don't actually want to create a button and simulate clicking it all inside the unit test; that'd be painful.
- You don't actually want to connect to a remote database, initialize the connection, and perform some SQL, all inside the unit test; that'd slow down your unit tests, and would also cause side effects.
Really, you just want to test your logic: it should respond to the Save button being clicked and then save the data to SQL. You could do this by injecting a fake/mock button and injecting a fake/mock database. Now you can write a unit test like this:
[Test]
void ClickingTheSaveButtonShouldSaveDataToDatabase()
{
// I'm expecting the fakeDatabase.SaveNewName method to be called.
mockFramework.Expect(myFakeDatabase.SaveNewName("theNewName"));// Simulate a click.
myFakeButton.Click();// Make sure our expectations happened.
mockFramework.Verify();
}Of course, this looks different for C++ frameworks, but the idea is the same. And it applies to all kinds of dependencies: databases, sockets, and GUIs are obvious ones. But you can fake everything, making your unit tests very concise; testing only the pieces you're interested in testing. Without mocks, unit testing would be very difficult and even impossible in
Sorry. I still don't get it. If it's a fake database, how can you verify that your SQL is working, especially if your SQL is contained if stored procedures? Maybe it's the same thing I've been doing in code all these years, and someone finally decided to give it some buzzword name. Still seems like smoke and mirrors to me (like "extreme" and "agile" development).
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
Oh, is this a new fad panacea, like "Strongly Ruthless Programming"? I'm not sure that mocking your objects regulary will in any way improve the code. Still, if I were SRP Stan, I could see the benefit: bad code will evolve because it hates being teased.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!|FoldWithUs! | sighistDidn't this use to be called "stubbing the interface". This sounds like some BS Project Management delusion. What is old is new again.
MrPlankton
-
Sorry. I still don't get it. If it's a fake database, how can you verify that your SQL is working, especially if your SQL is contained if stored procedures? Maybe it's the same thing I've been doing in code all these years, and someone finally decided to give it some buzzword name. Still seems like smoke and mirrors to me (like "extreme" and "agile" development).
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001John Simmons / outlaw programmer wrote:
If it's a fake database, how can you verify that your SQL is working, especially if your SQL is contained if stored procedures?
Write seperate tests for your database/stored procedures. For example, we might write another test for myFakeDatabase.SaveNewName method that actually *does* use the database. So why did we use a mock object? Simply put, for that particular test, we were interested only in testing our presentation logic. Trying to test presentation logic, UI, and data access all at once would merely muddy the waters and make your tests really complex. Instead, you split it up and test 1 thing (typically, 1 class) at a time. Make sense? The end result is code that's been thoroughly tested before you ever get to runtime. In practice, this results in you finding bugs before you ever run the app. Also, it helps when you go in and refactor code: if you make a bunch of changes, just re-run all your unit tests again, and you'll immediately be notified if you broke anything.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Triumph over evil: 40th Anniversary of the 6 Day War (audio) The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
A dnrTV show on design patterns suggests that the .NET market leaders are RhinoMocks and TypeMock in that order. What do others use, if any at all? The general consensus seems to be that RhinoMocks is the one to go for. I've just started playing with it.
Last modified: after originally posted -- Added that I've opted for RhinoMocks
Kevin
See Stop Designing for Testability to see why TypeMock is considered the Mercedes of Mocking
-
Sorry. I still don't get it. If it's a fake database, how can you verify that your SQL is working, especially if your SQL is contained if stored procedures? Maybe it's the same thing I've been doing in code all these years, and someone finally decided to give it some buzzword name. Still seems like smoke and mirrors to me (like "extreme" and "agile" development).
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001John Simmons / outlaw programmer wrote:
Sorry. I still don't get it. If it's a fake database, how can you verify that your SQL is working, especially if your SQL is contained if stored procedures?
One reason would be because you are working in a group and someone else is coding the database layer. So testing with that layer means that you have to wait until it is complete.
