Evolution of a hand rolled fake – part 4

Another hard problem when it comes to creating fakes is when the interface contain overloads (i.e. same method name but different parameters) like this: 1: public interface IYetAnotherInterface 2: { 3: int DoSomething(); 4: int DoSomething(int x); 5: } The Fakes utility in VS11 will generate properties like DoSomethingInt32 and DoSometingInt32Int32. Not great names IMHO….

0

Evolution of a hand rolled fake – part 3

So how do I fake an interface with properties? 1: interface IAnotherInterface 2: { 3: int SomeProperty { get; } 4: int SomeOtherProperty { get; set; } 5: } Most of the time I just let my fake have the property implemented. This works most of the time but only really well if the interface…

0

Evolution of a hand rolled fake – part 2B

While the last version I showed is very flexible I have experimented a little more. Why would you ever have a public getter on the fake handler properties? Maybe if you had a fake that needed to wrap existing fake behavior but this is probably pretty rare. So this is what it would look like…

1

Evolution of a hand rolled fake – part 2

In a recent discussion at work I realized that the main reason I started with the constructor based fakes descried here was not to clutter the object with properties called SomethingHandler. By having my fake implement the interface explicitly I could create a fake like this: 1: public class FakeTheInterface : ITheInterface 2: { 3: public…

0

Evolution of a hand rolled fake

I usually hand roll my own fake objects for my tests. They have always looked a lot like what Stubs generate. I just think that it’s so cheap to create them that I don’t even need Stubs. In this series I’ll assume an interface that looks like this: 1: interface ITheInterface 2: { 3: void…

2

Dependency injection and good design

I helped preparing a meeting on dependency injection on my team and we had that meeting last week and it lead to a number of interesting discussions. Before we go into that I have to explain the title (which was the same as the title for this blog post). If you look at attributes people…

0

Team coding dojo 2.6

We did Bowling this time. The group was satisfied with completing something. Or it was the donuts somebody brought in. We decided to aim for something closer to our day to day work next time so I have to come up with a Kata that includes the use of CCR. That will be fun.

0

Team coding dojo 2.5

Yet another MineSweeper. This time we let one person do all design work before we started and make all the decisions. Compared to previous sessions in meant we got a better coding flow but at the same time we did not open up to changes driven by the tests written. For the next time we’ll…

0

Team coding dojo 2.4

MineSweeper again. One thing that struck me today is that coding dojos with a new team is a great way of learning about other team members. Who wants to have a complete design, who likes to focus on error handling, who rushes forward without consideration etc. So there you are; another great reason to start…

0

Team coding dojo 2.3

Yesterday we did MineSweeper with almost no upfront design at all. We also had the biggest group I’ve been in for a long time. So we ended up being a little unfocused on the direction. A lot of minds pulling in different directions. It’s hard to find the balance between guiding the group and letting…

0