A friend of mine told me, “what you know and what seems to as trivial, might be completely new to someone else”. So I am trying to remember this, and once again the simple life wisdom proved to be correct. One of our team members had to be away while the team was conquering T/BDD and unit testing. As a result, he stayed a little behind, and as catch up exercise, we pared on a very simple problem, Calculator, another version of the classical “Hello World”. Maybe this will help someone someday.

I learned from a wise man that celebrating small successes as important as the having big one, if not even more. So today I would like to thank my team for the effort they made in such a short period of time and with a quiet a steep learning curve they had to go through. One picture is worth a thousand words.

Some statistics:

Project size - small

C# 3.0 has introduced lots of great features to make our life easier and syntax sweeter. Lots of people talked about it already, and I am not scooping here anything new. What I do want to demonstrate, is how to make the code easier to understand.

Confession is that I am relying on a tool to help me achieve what I will demonstrate – ReSharper. Not only it’s a great refactoring tool, but an excellent guide to C# 3.0 features (and not only). So lets roll to an example.

Today was a great day. One of the things we do with the team is experiment how we write our test. Experimenting seems the most effective way of figuring out what should be our testing approach. At this point we are mostly doing specification driven tests (unit tests).

We had a few questions in regards to code duplication and keeping it DRY and self-explanatory at the same time, hiding no important details. At the same time overwhelming details should not be annoying the test reader/explorer.

I was reading through the book when combined several subjects together, such as “help tests” and “error handling”, and realized that the core “Depend upon abstraction.  Do not depend upon concretions.” principle is underused by myself.

Normally, I apply this great principle when thinking of another not less good one - “Design to an interface and not an implementation”. And usually it happens when I generate new pieces of code. But this can and should be applies to an existing code as well, especially if it’s a 3rd party code. I am going to demo the concept along with the other subjects based on the book example, sorry for luck of ‘creativity on an early weekend morning’ :)

I finally got a chance to get to the next book on my reading list. Highly recommended book. “Uncle Bob” not only has produced a quality book, but also has captured a significant amount of wisdom that helps to make coding more rational.

It’s not a secret that I prefer certain tools/frameworks/applications over other ones. So is true with unit testing framework. My currently preferred one is MbUnit. My team was using NUnit so far, and honestly I respected the choice and didn’t mind that much. Until this week.

This week we moved to MbUnit (yupi!). Several reasons for that:

• Row testing was not possible - despite the NUnit.Rowtest extension, it was not working with R# unit tests runner
• Multiple assertions would fail if the first one would not pass
• Assert.AreEqual behaved weirdly

The last item was quiet a surprise. What happened is that we decided to try to be more expressive in our tests, and therefor substitute Assert.AreEqual() with extension method should_be_equal_to() allowing a more fluent syntax and human expressiveness (yes, side effect is abstracting away the unit testing framework, but that was not the primarily intent).

I have posted a question at VisualSVN user group in regards to reverting delete operation on an item in a project. The workaround is very much manual, and feels wrong. At this point I was either able to revert the change for the deleted file only and manually add it to the project, or revert both deleted file and modified project file, and manually remove the references to the files that are reported as 'missing'.

Lately I had an accident with my HP Pavilion laptop and wanted to share the HP service story with you. Hopefully it will save people time and money.

Less than a year ago I bought  a brand new HP Pavilion dv9000 17" laptop. The price was high, I was naive, and have decided to purchase an extended warranty provided by the store (Future Shop in my case).

11 months of a very  heavy usage, I happened to forget half a glass of Sprite beside the laptop. Boy that was a mistake. My ’little pup’ (accelerate Golden Retreiver) waved his tail and boom! Sprite on the keyboard. The fact that I shut it down, removed the battery, and turned it up side down has helped. The only issue was with a keyboard. Because of the sugar (this is probably another blog entry) in Sprite, keyboard became sticky inside and typing was impossible.

This is late news, but I really recommend listening to the podcast with Robert C. Martin on .NET Rocks! Decided to listen to this one as a result of the book have read a while ago, Agile Principles, Patterns, and Practices in C#. The guy who has spent over 30 years trying to figure out how to do software, has some ideas to inspire how you do things. Audience? Developers, managers, users. Anyone. This is a great content to listen to.