Finished reading “C# in Depth” by Jon Skeet. Good reading, especially if you have to  catch up from C# 1.0 or 2.0 to the latest 3.0. The other one I would like to read now will have to be a mix of this book (without 1.0/2.0 materials) and the excellent “CLR via C#” by  Jeffery Richter.

Until that mix is out, I am switching back to Domain Design/Modeling. “Domain Driven Design” by Eric Evans is the only one I read, loved, was confused with, and have to re-read. But what is missing is the practicality (the modeling part?). Would love to hear about the Domain Modeling books you have to recommend (and they don’t have to be necessarily in .NET neither C#).

Several last projects I used a simple IoC container, leveraging Activator.CreateInstance(type). The main reason - simplicity. Once there was a need to go to a higher level, I would switch to Windsor Container. One of the projects used Unity. The only issue was that I would always have to do some customization to my container (or DependencyResolver), which is nothing but a static gateway.

What I have decided, is that I do not want to invest effort in something that was working before just because the underlying implementation of container has changed. The container engine might be changed, but my code should not (OCP?). Therefore, DependencyResolver had to be coded slightly different. To make it possible, I decided to go with the LINQ Expressions. It allows to pass code in data structures, and thus allows to manipulate how to execute the code.

In the previous post I talked about running test in Resharper vs. TestDriven.NET

This time I will compare Visual Studio .NET 2008 (VS) with TestDriven.NET (TD.NET) for another functionality - quick code execution for evaluation purposes.

VS was shipped with a feature called Object Test Bench. The idea was to be able to instantiate an object of a class in order to execute it’s methods for quick evaluation. Great idea. The steps to have it going were multiple.

Seems like there’s a bug in Rhino.Mocks 3.5 in regards to stubbed dependency (stubbing property getter and a behavior in certain order). Anyone knows something about it?

PS: have posts at both Rhino.Mocks usergroup and stackoverflow, but still no clue what’s wrong.

My team is off the spike project we had, and I wanted to share a bit about exploratory tests.

The idea is to spike let’s say some 3rd party component. Just spiking is good, but not always enough. How to ensure that we transfer the knowledge we acquired during the spike to the coming generations of developers? Or how to document what we know about the particular version of the 3rd party component, so it can be verified with any other potential versions it (component) will have?

I used R# as a test runner tool. Nice UI (see my older posts), nicely integrated with Gallio. Just one issue - unrealistically slow when compared with a non-visual tool. And then our team member David showed us old-and-forgotten TestDriven.NET.

Oh boy, what a difference. It’s so much faster, than we jumped on it (almost) right away, leaving R# unit testing tool behind (though, not the R# itself :).

One weak side of TD.NET - executing all tests in solution or selective tests execution grouped, it’s not there. Yet, this is not an issue, for that we should leverage automated build scripts, right? :D

During the scrums we report what we did yesterday, planning to do today, and what are the impediments. Impediments sometimes tend to sound like a complaint. So what to do to prevent it become just “bitching” about things?

1. Don’t complaint. Bring impediment to an attention with a very short and pragmatic preposition how to remove it. If you can’t make such a note or just don’t have one, don’t complaint (“Report impediment, not complaints”).

There are multiple ways to estimate time for a user story. One of the ways that worked really nice for my team was personal estimates discussed by the developers together (Estimate Poker game?). This is how it goes.

User story:

As a Sender, I want to be able to query status of my document, so I could know it’s location.

Each develop would grab a pen and paper, break down the user story into tasks that will be required to implement the user story and estimate each task. At the end the total estimate is written down.

This is not the first time I came back to automated builds and re-evaluate how they are done. This time, I wanted to capture several things at the same time:

1. Specifications and Integration tests have to reside within the same project with the SUT, so that there’s no need to maintain 2 separate projects structures and keep them in sync.

2. Ensure that visually we be determined if a class has Specifications or/and Integration tests (SomeClass.cs, SomeClass_Specs.cs, and SomeClass_Integration.cs)

Today one of our team members brought up a valid question - how do I know that my SUT (system uder test) packages the primitive parameters (username and password) and sends into dependency object as a DTO. Maybe instead of packaging into DTO the primitive values it packages something else by accident. The proposed solution was a dedicated Factory per each DTO (contract and implementation). For testing purpose it was great, but from the design perspective this is an absolute no-no. Lets review what we have and what we want to have.