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...

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...

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 with no public...

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 Something Handler . By having my fake implement the interface explicitly I could create a fake like this: 1: public class FakeTheInterface...

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 DoSomething...

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 tend to claim...

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.

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 try something...

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...

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...

Today was the second time I organized a dojo in my new team. We did the MineSweeper and it turned out interesting as usual . The highlights today was how the design got pushed in one direction by a typo in a test. The typo made us expose the internal representation of an mine field before the sweep which...

Yesterday I had my first Coding dojo with my new team. We did FizzBuzz in the same way I've done before . Turned out to work pretty well as a first dojo where nobody had participated in a coding dojo before. If I could do it again I would probably not have the faked dependency in the Printer class. And...

A while ago I was asked how to handle the case where setting up unit tests became complex because you wanted to test at a lower level. Since that question itself confused me I tried to understand the problem and it turned out that person started by writing a test for some high level abstraction faking...

Yesterday was about writing good test fixtures rather than using a tool that makes you get away with bad designs. The same thing goes for mocking frameworks . If you use a mocking framework you should avoid using it do fake things you wrote yourself. And you should use it rarely for anything else. That...

This week I held a brown-bag on TDD and coding dojos in my new team . The key point was that TDD (or unit tests without TDD) should not be about writing tests. It is about documenting behavior and writing good code. As a side effect you get a test suite that make you confident your code works as intended...

The answer is no - a professional developer should always use BDD. No seriously. I read this today and didn't hesitate a second to steal the topic since I there are two discussions around TDD I love; the discussion with people who struggle to write good code and the discussion with people who write...

I've previously mentioned what a coding dojo is but never really covered why you should go. I wish I could just direct you to this lightning talk from 2009 . The slides are in English but the talk is in Swedish. I guess a summary of the lightning talk is that you go to a coding dojo to learn and share...

I decided to add a few double Ds to my old list . First up is FDD as in Fun Driven Development . FDD is when you only focus on what is fun at the moment. This may sound great but probably also leads to a number of unnecessary features just because they were fun to implement. You should have fun developing...

As you may know I think mocks should be used quite carefully . But as I've pointed out before I think you should use the best tool available and that means to use a mocking framework sometimes. One thing I've never really liked with the typical mocking framework is how it requires you to learn a new...

Last year I wrote the same test in 24 different ways as a little advent calendar for you to enjoy. This year I'm going to do something similar but also a little bit different. I'm going to start with a simple piece of code and then show how this code can be tested for thread safety in different ways...

Yesterday was the fifth MSFTCorpDojo . MineSweeper as usual and we tried switching person at keyboard on each arrow in the TDD cycle (and not really pairing). As last time we tried BDD style tests. Didn't end up quite as neat as last time but we still learned something. I also noticed that everybody...

This time we took the completed BankOCR Kata from last time and tried to refactor it using the object calisthenics rules . It was really fun and the dojo was quite different from the other dojos which has been more TDD focus. This time we had a lot of design discussions and we had to force our selfs...

I've heard that some people don't think the CodingDojo site tells you a lot about what to expect in a coding dojo. It's more about practical things and listing a number of good problems to solve during the dojo. So I'll try to elaborate. In a coding dojo you will learn something. It might be TDD if you...

Fourth MSFTCorpDojo today. MineSweeper and MicroPairing this time too.This time we, as a result of the retrospect from last time , we did BDD-style testing (I've added one of the test classes below as an example). We decided to start by implementing a parser that parsed the input and created an internal...

So I previously mention a neat way to set up visual studio to work with a console test runner so you don't switch to the error list all the time. There is a potential problem here. Sometimes you add a compilation error to the code. In this case the post build step will still be executed with the old...