An interesting podcast, and I especially like the concluding thought.
For me, mock frameworks are not something that lets me escape the pain, but a way to keep my focus on the method where the main specification is written, so it's really a faster way to type simple stuff.
I know that some mocking frameworks support things like recursive mocking (so that you can mock calls like x.Y().Z().V()) - this is one of the ways mocks can be overused, since by using this feature, we break encapsulation badly. I wish someone removed this feature from the framework I use in my daily work :-D.
By the way, one point that needs clarification in my opinion. You say that mocks are part of specifications and that they should be as simple as possible. So, which of the two examples is your preferred way of handcrafting mocks (let's say that we have two specifications that specify what happens if some complex condition is fulfilled and what if it's not):
1. public class FulfilledMock : Condition { public boolean IsSomethingFulfilled() { return true; } }
public class UnfulfilledMock : Condition { public boolean IsSomethingFulfilled() { return false; } }
2. public class ConditionMock : Condition { public boolean isFulfilled;
public boolean IsSomethingFulfilled() { return isFulfilled; } } ------ So this is really a question on how generic should handcrafted mocks be.
In terms of automocks, stay tuned. We'll have a blog just on them very soon.
In terms of mock complexity/genericism, we *think* we'll answer your question in part 2 of Testing the Chain of Responsibility (just redid part 1 entirely). Working on that as we... type. You'll have to let us know if we answered you or not.
An interesting podcast, and I especially like the concluding thought.
ReplyDeleteFor me, mock frameworks are not something that lets me escape the pain, but a way to keep my focus on the method where the main specification is written, so it's really a faster way to type simple stuff.
I know that some mocking frameworks support things like recursive mocking (so that you can mock calls like x.Y().Z().V()) - this is one of the ways mocks can be overused, since by using this feature, we break encapsulation badly. I wish someone removed this feature from the framework I use in my daily work :-D.
By the way, one point that needs clarification in my opinion. You say that mocks are part of specifications and that they should be as simple as possible. So, which of the two examples is your preferred way of handcrafting mocks (let's say that we have two specifications that specify what happens if some complex condition is fulfilled and what if it's not):
1.
public class FulfilledMock : Condition
{
public boolean IsSomethingFulfilled()
{
return true;
}
}
public class UnfulfilledMock : Condition
{
public boolean IsSomethingFulfilled()
{
return false;
}
}
2.
public class ConditionMock : Condition
{
public boolean isFulfilled;
public boolean IsSomethingFulfilled()
{
return isFulfilled;
}
}
------
So this is really a question on how generic should handcrafted mocks be.
In terms of automocks, stay tuned. We'll have a blog just on them very soon.
ReplyDeleteIn terms of mock complexity/genericism, we *think* we'll answer your question in part 2 of Testing the Chain of Responsibility (just redid part 1 entirely). Working on that as we... type. You'll have to let us know if we answered you or not.