Criteria involving multiple ORs and ANDs can quickly become ugly. David showed how some of our code became more readable by using a feature to join multiple *ICriterion-*s instead of using Restrictions class (as well as how to quickly leverage expressions to get away from using property names, and allow better refactoring by replacing strings with compile-able code).

James Gregory has provided earlier a very simple explanation on the subject. Absolutely love when things become simpler!

I ran into a problem once in a QA environment, and it was unpleasant to handle. Amr ElGarhy has showed a way “baked into” .NET how to overcome issues similar to the one I had – write emails straight into file system. Solutions is elegant and done through configuration file.

Convention over is defined in Wikipedia as follow:

Convention over Configuration (aka Coding by convention) is a software design paradigm which seeks to decrease the number of decisions that developers need to make, gaining simplicity, but not necessarily losing flexibility.

Our current project, that is no longer a skinny cow, has a state machine of message statuses, and a factory that can produce the state object from a key. Today I ran into a bug, when added two new message states, but forgot to update the factory, that happened to reside in a completely different assembly from the one that contains state classes. After a quick trace the bug was found. But how painful it is:

“Two better than one”.

“Once you try it, you never go back”.

Productivity can be achieved in multiple ways. One way is to provide developers with multiple monitors to minimize context switching and allow more real estate for concurrent usage. NEC Productivity Study lists a few factors users like about dual monitors:

• Faster
• More effective
• Easier to use
• More viewable space

Out company provides employees with laptops and an additional screen by default. So theoretically you end up with two monitors. The problem, is that laptop monitor is 15” and it’s resolution does not match (usually) larger monitors with higher resolution. Today, thanks to Victor, I have installed eVGA’s UV+ to enable 3rd monitor. Now I can really work. Each monitor has it’s dedication:

Write your test code as you would write your production code. In my opinion, a few of the most critical things are:

• Understanding (Readability and clarity of what the code is doing)
• Easy of change (be able to reflect changes)
• Quick safety net (understand what goes wrong and why)

In one of my previous posts, I have blogged about test naming conventions, that is popular among BDD adopters, and starts to pick up among classic-TDD followers as well. Seven months later, I can see where all the bullet items are missing in classical TDD, and present in BDD.

After reading “Implementing Lean Software Development: From Concept

Mary and Tom Poppenieck have greatly captured so many aspects of software development and how to do those lean way.

Found this great excerpt in a book:

Principles are guiding ideas and insights about a discipline, while practices are what you actually do to carry out principles. Principles are universal, but it is not always easy to see how they apply to particular environments. Practices, on the other hand, give specific guidance on what to do, but they need to be adapted to the domain. We believe that there is no such thing as a “best” practice; practices must take context into account. In fact, the problems that arise when applying metaphors from other disciplines to software development are often the result of trying to transfer the practices rather than the principles of the other discipline.

I have finished reading the book and wanted to write a short review, but

pros

1. Smooth introduction, complexity is added step by step
2. “Strict mocks are causing brittle tests” – more than that, it causes to get into the private details of execution, rather than overall design and behaviour
3. “Method strings are bad inside tests” – absolutely
4. “Mapping tests to projects” – very right decision to spend time on the subject and show a right example
5. One-test-class-per-feature pattern is mentioned (music to BDD fan ears)
6. Writing maintainable tests – critical topic that was covered
7. DRY in test code – in general I agree that an unnecessary duplication should be removed from the test code. But there’s a think line that should not be crossed – tests should be readable and maintainable. For that, duplication sometimes is necessary. This is the less evil for a bigger cause – readability and maintainability.
8. Row testing is showed
9. “Integrating unit testing into the organization” – a very, very useful chapter, especially if you have to pioneer the field at your work place. Personally, I wish I would read this long time ago.

cons

1. Tests naming conventions
2. Too much is dedicated to Stubs and manual Mocks
3. Chapter 5 - Isolation (mock object) framework is explained with Rhino.Mocks Record/Playback rather that AAA that is more natural

• Note: AAA sample is showed, but after Record/Playback, which IMHO is a wrong way of teaching it. AAA is more intuitive and sticks more than the opponent.

5. TypeMock promotion – Roy is working for TypeMock that is a commercial tool. He could definitely use an OSS framework to show AAA mocking framework, like Moq framework. In an absence of a free tool, I would accept TypeMock as an example, or as a part of available commercial tools. (Page 130 shows the distribution of popularity, and Rhino.Mocks with Moq are the two most popular free mocking frameworks). This was a promo for the tool… not nice.

• Note: I am not a big fan of the fluent naming TypeMock is using. Isolate.Fake.Instance() is two verbs that are not intuitive.

7. Naming conventions for tests – both unit tests and integration tests are suffixed with a single word “Test”. I would rather distinguish and use context “Spec” and “Integration” as an example.
8. One-test-class-per-class pattern – for someone who’s doing BDD this is an anti-pattern. One big test class is a smell. It leads to brutal test code that is not only difficult to maintain, but even understand from it what it is doing. Very typical to the classical TDD.

• Note: Roy has provided a tip on this, politically correctly hinting that not everything from the big heads (Meszaro in this case) is always an absolute must.

10. Assertion with Extension Methods to improve tests readability was not showed at all

• Note: IMO Assert.AreEqual(found, expected) is confusing. I prefer to reveal intent with a code like result.Should_Be_Equal_To(expected);

12. NO BDD SAMPLES – BAD BAD BAD. I strongly believe that just with classic TDD testing is not complete. BDD is the next step in the right direction, and skipping it entirely was a mistake.

Conclusions

If you are a newbie in TDD or just “checking it out” – go for this book, worth it. In case you already have experience in TDD/BDD, and you are doing it for a while, it will not add much to your tool belt. Either way, the book is welcomed, and I am excited that more and more of this kind of literature is becoming available for .NET developers. I only wish the next version will be written BDD style, right Roy? ;)

I was chatting with an old mate of mine, Lev  Ozeryansky, with whom we graduated together computer science about 8 years ago (man, that was long time ago, but doesn’t feel like that). He’s a great developer, with lots of experience. Yesterday we have finally met and chatted a bit (guess about what). Two things I heard bothered me a lot.

1. You need more than 2 developers to do pair programming and being effective.