August 25, 2010 TDD, TeamWork, UnitTesting No comments
August 25, 2010 TDD, TeamWork, UnitTesting No comments
Few days ago I worked few hours on Sunday, so there were only me and one of my co-workers in the room. He is Delphi guy, but likes to learn .NET. He had to implement some custom resizing logic for the report and he asked me if I can help to think on the logic. We had spent maybe couple of minutes before we got some preliminary ideas.
Let’s do Pair Programming
We decided to implement some prototype/logic within .net. I suggested pair programming with TDD: “I will be writing tests – you will be implementing logic to make them work”. BTW, do you know how do we call this particular programming pattern? – It is called “Ping-Pong Pair Programming“.
So after I created basic test project and wrote a test that simply has something like “var report = new Report();” and then “report.Draw();“, which of course is failing UT, he proceeded with creating class for Report and putting in place stub method Draw. Then I added functionality that allows adding report columns, then sizing of them, desiredMinimalWidth and delimiting width. Then UT that verifies if we correctly resize columns, if they fit or do not fit into report. Misha was performing extremely well in implementing logic, we had been thinking on. At some point of time he got stuck, so we continued together on making latest UT work.
I enjoyed this try of doing Pair Programming along with TDD.
What are benefits of doing PP as per me?
Are there disadvantages?
It might happen that PP will not be feasible, especially in situations when problem they are trying to solve is trivial or when one of contributors is not interested in going great job. You can read lot of discussion over the internet about the time PP consumes and the quality of the work. Most commonly you will hear that when doing PP it takes +15% of time if two developers work independently and produces 15% fever bugs.
What are preconditions on doing Pair Programming as per me?
In my further professional growth I will try to involve more people in this practice!
July 3, 2010 RhinoMocks, TDD, UnitTesting No comments
Are you married? Yeah, quite not usual question for blog post about mocking, but if you are married you probably asked your girl to become your wife.
So you are playing role of PotentialHasband:
and she is PotentialWife, taking your ask into consideration and answering you true or false.
If she is Linda, you would need to have “I love you” in your speech to get her agreement:
What we are going to test is to see that after you asked, she will definitely give you at least some answer and not ignore you. Also if her answer is “YES” we would like to see MarriageService called Marry method.
Class which we are going to test is named LearningMocking and has constructor that accepts potential husband/wife and marriageService. Whole story takes place in RestaurantDinner method.
First let’s test that after you asked she gives at least some answer. Since we are not interested in concrete instances we just generate mocks for our interfaces, and passing null instead of marriage service. I’m using RhinoMocks in this example.
This ensured that at least she will give you some answer. In next test we will have some mix and will use concrete class Linda. We have generated Stub for return value of your speech, so instead of
writing concrete class for husband we’ve used stub. This test shows that
she will not marry you:
Let’s use another strategy to ask Linda:
Except of verifying that Marry method was called we also verify that it was called with instance of linda and none else with line Arg<IPotentialWife>.Is.Equal(linda). As well you could setup constructor arguments for MarriageService, since it is not an interface. Also with Rhino.Mocks you will need to have method Marry to be virtual. If it is not virtual and you don’t have interface for it you may need to extend that class with your own.
In the end we’ve got this method:
Nice picture:
Please write down if you would like to see more complex mocking examples.