But how could a test drive design??

Good question, I'm glad you asked...

Actually, I asked myself during my long a** commute, which gave me a lot of time to reflect.

The weird thing about TDD is that there is no design.

You don't design tests. You write them, one at a time.

This is something that makes TDD difficult. Even after I understood the basics, it was still a challenge to stay with it. I had to stop thinking about how to solve the problem and focus only on how to test the solution.

It's not that I don't think about designs at all, but I'll only design up until the point I know I'll be able to start my first test. This design is focused on high level interactions and the goals of my solution.

When the TDD light bulb went off above my head, my thinking changed to this:
What can I do to make this test as easy as possible to write?

Thats it. Kinda lame looking at it now, but really, thats it. When I focused on testing and that alone, that's all that remained.

If you have difficulty dispelling design noise, pretend you are Harry Potter and have your very own pensieve (that would be pretty cool, no?). Put the thoughts in the pensive. They will be there when you have the focus they deserve (In real life this works well with index cards)

Unless it is a new user story, I throw it out. I don't worry about it, because if I need it, it will happen.

But what if I forget? Are my user stories satisfied? Are my acceptance tests passing? I guess I don't need it.

But I need to refactor my code! Well, I should be doing this all the time! If I didn't have a chance for whatever reason, next time I am in the test, it will be so painful, I'll refactor. I trust myself and my team. When this happens a lot, I need to think about what done means (this is another topic)

How do I make tests easier to write?

When I can't make a test without getting frustrated or overwhelmed with what-ifs or setups, I introduce a mock and encapsulate the behavior. Using that mock just made my life a whole lot easier.

Did I just drive the creation of a new interface? Is there a new interaction that didn't exist because it was the easiest thing? Will my class be more simple because its not doing something too complicated? Will the new class be cohesive because it was created for a specific purpose?

Wow, not only am I creating a new design as I go, but all other things happen because I'm trying to make my life easier.

Anyone else see the beauty here?

Or the power?

When I have a very complicated problem, I break it up organically by test driving. Each part not only makes sense, but is easier to implement because I am able to focus on small pieces. I have instant gratification that each worked on its own, as it was created, without any integration.

Sweet bonus, the solution doesn't do anything extra and I didn't go on any tangents because I didn't want to write extra tests.

Extra sweet -- I spoke to coworkers, took a lunch break, wrote a blog post and had NO fear my momentum or focus would be lost.

Writing tests is more difficult than writing code, but when I focus on making my tests as easy as possible to write, it keeps me in the test, drives my design and simplifies my thinking.

More about → But how could a test drive design??

Xna Feature Request

Kris is soliciting votes for an xna feature -- GameServiceContainer.GetService<T>
(i.e. Make GetService support Generics!)

Follow the link and click "vote now".

Use your MSDN/Live credentials to log in.

If you get a page not found error, you need to complete registration for Microsoft Connect -- go to the "My Participation" link in the left menu.

More about → Xna Feature Request

No-Bake Chocolate Cheesecake

Made this no-bake cheesecake with a pack of Kraft's Philadelphia light cream cheese. It is supposed to be a Triple layer chocolate cheesecake. But you can see from the photo, it didn't turn out as expected. The three layers were not clearly distinctive :(

I guess the proportion of the dark and white chocolate was not right for the middle layer...as I sort of mix and match recipes to come up with this version. The original recipe uses 40g dark chocolate and 40g white chocolate for the middle layer. If I were to make this again, I will change it to 20g dark chocolate and 60g white chocolate. Nevertheless the cheesecake tasted very refreshing and light as I used yogurt instead of whipping cream.

Ingredients:
(makes one 18cm cheesecake)

for the base:
110g digestive biscuits, crushed into fine crumbs
60g butter, melted

for filling:
250g cream cheese, soften at room temperature
60g caster sugar
200g non-fat plain yogurt
2 teaspoons gelatin powder
3 tablespoon water
100g dark chocolate, melted
140g white chocolate, melted

Method:

1. Mix biscuit crumbs; melted butter together and press firmly with the help of a spoon onto the base of a 18cm round pan. Chill for 30 minutes.


2. Place gelatin powder and water in a bowl. Heat a pot filled with some water until just simmering and place the bowl inside the pot. Dissolve gelatin and water in the bowl. Keep warm.


3. With a whisk, beat cream cheese till soft. Add in sugar and whisk until smooth and creamy.


4. Add in yogurt and continue to beat till smooth. Blend in gelatin solution and mix well.


5. Divide cheese mixture into 3 equal portions.


6. For the 1st portion, stir in 80g of melted dark chocolate and spread evenly on the biscuit base. Chill in the fridge for a while. (I pop it in the freezer while preparing the 2nd layer).


7. For the 2nd portion, stir in mixture of 20g melted dark chocolate and 60g melted white chocolate. Spread over the 1st layer. Chill in the fridge for a while.


8. For the 3rd portion, stir in 80g of melted white chocolate. Spread over the 2nd layer. Chill for 3 to 4 hours before serving.

Tip: You can melt the chocolate in 3 separate bowls, ie 80g of dark chocolate in a bowl, 20g dark chocolate plus 60g white chocolate in another and 80g of white chocolate in a 3rd bowl.

More about → No-Bake Chocolate Cheesecake

Pair programming, team ownership and collaboration -- Oh crap!

For me, like many others in our field, talking to people and collaborating wasn't as natural as coding and designing.

I never needed to talk out a design, it would just happen. I loved creating software and I was quite good at it. In a few short years I went from code monkey to architect and project engineer.

In all this time, I never developed a sense of team, community or sharing. I had a hard time communicating my designs; I never thought about them, I just did them. I had difficulty listening.

When I first got to Oxygen, with only pair programming, I was completely frustrated. I was use to excelling and being the hero of the team.

At pairing and communicating I, well, let's just say it didn't come so naturally.

For me, the most difficult part of pairing and code ownership is giving up what's best for you and substituting it with what is best for the team. This is a concept that is very important for the entire team's productivity and happiness.

In our world we have a lot of brilliant developers, with a lot of brilliant ideas. Our designs are more of an art than a science and with any art, it is a personal expression. This is why collaboration, sharing and pairing is so difficult -- in our minds our design is always really good.

And for each individual that is true.

But for someone else, a solution that brings you great success may bring them great frustration and pain.

What is the solution? How can we all agree? In what ways can we share our knowledge?

I'm not sure... but I think about it a lot.

While differing opinions can bring the best ideas, spending an entire pairing session (or worse days, weeks, forever) bickering about differing opinions is much worse than not bringing your ideas to the next level.

In pairing, when you have two opinions, the best option is to choose an opinion and run with it. If its not the right solution, it will be obvious right away.

However, sometimes its not a wrong decision, its just not the better solution and the pain of the decision may not be felt at that moment.

Will the frustration of the person be felt in the group? Probably not if they are sometimes heard. If your environment has a few people who are more stubborn than others, you may have some frustrated developers who need to get their way more often.

On any team, with each pair, you will eventually find a groove. How long it takes and the style of your solutions with depend on the individuals of the team. And the style you find may be completely different than what you do on your own.

Whatever gives your team the ability to keep their velocity, happiness and quality high is the best practice.

More about → Pair programming, team ownership and collaboration -- Oh crap!

TDD, What a bitch

Whenever I talk to someone who is interested in learning TDD I let them know that it is a very difficult concept to put into practice. It takes a lot of discipline and significant changes in the way you think and code.

Nobody mentioned this to me before I started. Everyone spoke of TDD like magic -- it changes your design, its the best thing ever, its so simple, all you need to do is write your tests before your class, you'll love it... (Ignore the man behind the curtain!)

After a few days of trying, I began to think something was very wrong. I wasn't quite the developing genius I thought...

That couldn't be true!

Like any reasonable person in my situation -- overstressed, too many responsibilities, tight deadlines, stakeholders bothering you, etc... I continued to pound my head against what seemed to be a steel wall of TDD that just wouldn't fit.

My head (now bleeding and bruised) was focused on how to solve the problem instead of how to test the solution. I didn't know it at the time, but until I changed this behavior, I would always be fighting my instincts and not gaining the benefits.

Fast forward two months and I was still, well, sucking, but not as bad. I had some test coverage, I wrote some classes test first, but I did not test drive every class, it seemed like too much work. I also didn't understand mocks, at all, and gave up on writing my own mock classes after about a day, so no interaction testing and lots of coupling.

It was very frustrating to have 1/3 of my tests fail if I was working on a common entity or if a bug showed up. Also, because I was coupling all my classes together I wasn't seeing the full benefits of test driving.

My focus was just as bad as coding before. If I needed a new behavior, I'd have to code. This meant testing the other class, which may cascade into other tests. Thinking about it, I think my focus was worse. Sometimes I could write a stub for the new behavior, but say I was creating a method that returned a boolean that had different responses that I needed to test... And there is the setup to get it into each state. And thats just a boolean assuming there's no interactions...

My thinking was in the same place it was a few months earlier. The only difference was I could write a unit test before I wrote code. But I wasn't test driving design. I had the design in my head. I was writing the unit tests for the classes and interactions I already decided I needed.

Fast forward two months: New job, new project, fresh start, woo hoo!

With this project, I was determined to understand TDD. A lot of bright people that I respected were saying great stuff and I was going to get it.

My first step was to understand nMock.

I knew using real classes in my tests was killing my focus, but I didn't yet know how much it affected my design. I read the nMock web page, explaining the api, about 500 times... "Okay," I said to myself. "You can use an interface before its implemented and verify its been called."

It sounded so simple, it read so simple, yet it made NO sense to me.

My delight in using mocks (once I figured out how to use them) was focused on several things -- I could focus on the test I was writing, my tests weren't failing because of another class and my tests were a lot simpler because I didn't need to put in knowledge about other classes to verify or assert behavior in the CUT. Implementations of interfaces used in tests didn't affect the tests anymore.

After a few weeks of nMock, what I began to notice was that my design, code, thinking, and mind was changing.

A lot.

I only made a class after it was being used as an interface in another class. That class' only public methods were in that interface. I never debugged my application. I almost never debugged my tests. My test coverage was over 90%. My design evolved through the tests.

I was test driving. Finally!

Making tests was so focused and had immediate results I was addicted. At some point, something happened in my brain and this great thing called TDD finally came in. I didn't want to write in the CUT first, because it wasn't how I was thinking. It seemed like more work.

I was in the test.

More about → TDD, What a bitch

Chocolate Marble Bread

I finally made it! This is my second attempt on a chocolate swirl bread...it is definitely much better than my previous attempt.

I realised that in order to prevent the chocolate from oozing out from the dough, the texture has to be right. The first time when I did the chocolate paste, it was too soft. The trick is to cook the chocolate paste till very thick and almost dried out...forming a big lump. The texture is almost like a soft cookie dough.

As I needed to use up my whipping cream before it expires, I used the Hokkaido Milky loaf dough instead of the dough recipe from the chocolate swirl bread. I made the chocolate paste while the bread maker was doing the manual work of mixing and kneading.

Here's how the dough looked like when it was plaited, ready for the second proofing.


The dough rose beautifully during the second proofing, but my shaping skills need further improvement. I wasn't able to achieve an even loaf...one of the sides was smaller than the other!


The finished loaf....all swirly and twirly...I was so glad that this time round, the top was not burnt. I've learnt that as the heating element of my oven is located on the top, I'll have to bake the bread on a lower rack position to prevent the top from burning. I positioned this loaf such that the top of the bread was at the centre of the oven. I was so pleased that the bread was browned evenly all over :)



I didn't really follow exactly how the dough was supposed to be rolled and shaped as given in the chocolate swirl bread recipe. Instead I adopted the rolling and shaping method of a basic danish bread. I was also too lazy to chill the dough in between the shaping, rolling and folding...I simply did it in one shot and let it proof. Luckily, the marble effect turned out great.



This is indeed a very interesting bread...each slice has got slightly different swirls...and the exciting thing is, you won't know how the marbling effect will be until you slice the loaf =)

and here's how I did my quick and easier version of the chocolate swirl bread.

Ingredients:
(makes one small loaf)

chocolate sheet
20g cake flour
50g sugar
1 egg white
80ml milk (warmed)
18g cocoa powder
10g butter

bread dough
270g bread flour
30g cake flour
5g active dry yeast
15g milk powder
40g caster sugar
4.5g (3/4 teaspoon) salt
125g fresh milk
Half an egg
75g whipping cream (heavy cream)

Method:

chocolate sheet

1. Mix sugar and cake flour into the egg white until smooth.
2. Place milk in a saucepan and heat till just simmering.
3. Add coca powder into the milk and stir till cocoa powder is incorporated into milk.
4. Add egg white mixture into the cocoa mixture and stir over low fire till mixture thickens and form a thick lump.
5. Add in butter and stir till incorporated.
6. Leave to cool. Place in a plastic bag and roll into a square (about 14cm x 14cm). Keep refrigerated before use.

bread dough

1. Place all ingredients in the bread pan of the bread machine, according to the sequence stated in the instructions of your bread machine. Select the Dough function to knead and proof the dough (about 1hr 30mins).
2. Take out the dough and punch out the gas produced. Roll out the dough into a rectangle (about 45cm x 20cm) on a lightly floured work surface. Place the chocolate sheet on the middle of the dough. Wrap both ends of the dough over to cover the chocolate sheet completely. Take note that the dough should be rolled long enough for both sides to fold over the chocolate sheet, leaving a border edge of about one inch. Seal the edges tightly. The dough should now be about 15cm x 20cm.
3. Roll dough from centre to the edges to form a rectangle (about 45cm x 20cm). Do this gently to prevent the chocolate paste from oozing out. Fold the dough into 3 folds.
4. Repeat step 3 above. (If you want to create more swirls, repeat this step twice.)
5. Finally, roll dough to 30cm x 15cm. Make a cut in the middle (length wise) leaving an inch uncut. Twist and plait. Place plaited dough in loaf pan and let proof for another 30mins or until the dough rise to about 80% of the loaf pan.
6. Preheat oven to 200 degC but bake at 180 degC for about 35 - 40 minutes. Remove from oven and unmould immediately. Let the loaf cool off before slicing.

More about → Chocolate Marble Bread

Sweet Potato Bread

These Japanese sweet potatoes have beautiful purple/pinkish skins, although the insides are orange. They are sweet and moist. I would usually boil them and will eat them plain. They taste really good when piping hot!

I used these sweet potatoes to make a loaf of bread. I omitted the roll oats called for in the original recipe and substituted muscovado sugar with plain sugar. The loaf was easily made with my bread machine using the basic function.

The texture of the bread was a little dense and rather moist. The taste wasn't really fantastic, but neither was it too bad. I couldn't really taste any flavour from the sweet potatoes though.

I will not post the recipe here as I wasn't quite sure whether I got it right?!

More about → Sweet Potato Bread