sfeldman.NET

Tests Maintainability

Sean Feldman — Tue, 14 Jul 2009 05:05:00 GMT

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.

True story example

In BDD we have Specifications and Observations breakdown. The classical TDD is missing this aspect. So a specification like the follows,

        1: public class When_DomainService_is_asked_to_to_deliver_a_message_and_exception_is_thrown

       2: {

       3:     [Observation]

       4:     public void Should_recover_and_log_exception()

       5:     {}

       6: }

looks as next in classic TDD.

       1: ShouldRecoverAndLogExceptionWhenDomainServiceThrowsFaultExceptionAndDeliveryQueueServiceThrowsFaultExceptionWhenAttemptingToDeliverMessage
  

Readability / clarity is definitely compromised. A single word of 138 characters looks a bit complex.

Ease of change is not quiet simple in classic TDD case – you first have to de-crypt what the test actually does before updating test/production code.

Safety net – in this case we are on a thin ice – developers who have a problem to “de-crypt” the test code to figure out what went wrong, will eventually end-up either disabling tests for new code, or worse, removing old tests as well. And that happened in the past.

The moral of the post – BDD is all about the behaviour. Let the old habits of classic TDD-ism go away, accept that testing code is a first class citizen as the production code.

Lean Software Development: An Agile Toolkit - The Book

Sean Feldman — Sat, 27 Jun 2009 15:24:00 GMT

After reading “Implementing Lean Software Development: From Concept to Cash”, I decided to look at the original book. It is as good as the successor. IMO reading the original one first even better than just skipping to the new version.

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

Building Software vs. Building a House

Sean Feldman — Thu, 25 Jun 2009 13:49:00 GMT

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.

So true. How many times you’ve heard software development compared to constructions or any other discipline?

The Art of Unit Testing – The Book

Sean Feldman — Wed, 24 Jun 2009 10:54:00 GMT

I have finished reading the book and wanted to write a short review, but the best I could come up with is a list of cons and pros. Lame, I know, but this will give you a hint at least.

pros

Smooth introduction, complexity is added step by step
“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
“Method strings are bad inside tests” – absolutely
“Mapping tests to projects” – very right decision to spend time on the subject and show a right example
One-test-class-per-feature pattern is mentioned (music to BDD fan ears)
Writing maintainable tests – critical topic that was covered
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.
Row testing is showed
“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

Tests naming conventions
Too much is dedicated to Stubs and manual Mocks
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.

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<IWebService>() is two verbs that are not intuitive.

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

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);

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? ;)

Breaking Myths

Sean Feldman — Tue, 23 Jun 2009 04:20:00 GMT

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.

2. TDD is a waste of resources (where resources are developers, money, time, you name it) and only possible in big companies.

Lev was doing TDD, but he was the only person to do so. Why didn’t this work for the entire company? It was considered a waste. Worse that that, it was mandated as a waste by the management to the point where developers believed in it. What a waste… Immediately I thought just about the blog published lately – management has got to buy into this and adopt, and it’s a developer role not to give up on change promotion.

As to the first point, about pair programming, well… Personally I am a huge fan of pair programming for multiple reasons (final code quality, knowledge transfer, overall design, better testing in place, etc). I agree that it is impossible (and from the psychological point of view even not always desirable for certain individuals) to pair a 100% of time, but even 2 developers in a shop will do a huge difference by pairing.

Along with that I am no longer surprised that bigger companies are adopting both. Not just because “they have more money to waste”, but since they have already “wasted enough to realize that something was absolutely wrong”. If I would be today in a position of a start-up, yes, I would think twice before throwing these two aspects into the game. In case of a running shop – no thinking. Just do it, unless you want to vanish quickly among piles of in-maintainable legacy code in the suffer-land.

Code Leader – The Book

Sean Feldman — Fri, 19 Jun 2009 06:57:00 GMT

On my flight I had a chance to finish reading “Code Leader” by Patrick Cauldwell. The book is a good source for ideas and concepts that “solid” developers should employ on a daily basis. Topics such as TDD, build vs. buy, CI, choosing the right tool for the right job, contract driven development, and much more.

The book goes over subjects showing tidbits of everything, and could be probably expended and extended at least several times more. But then it would probably become “Clean Code” and “Agile Principles, Patterns, and Practices” clone, which author probably didn’t want to create.

Overall, I liked the book as an introduction to so many “Alt .NET” concepts in a single source. What I missed in this book is the human leadership in the code, the human-factor in code creation, the behaviour and interaction between people that work on the same software. IMHO, code leadership is not only superiority in machine code, but also in the team environment.

Quality Software

Sean Feldman — Sun, 14 Jun 2009 03:39:00 GMT

I am on my vacation, and not suppose to brag about software, but something has happened on my way to Israel, that just couldn’t go away silently. To get from Calgary to Tel-Aviv, I had to fly with Lufthansa for 9 hours first. The Airbus 340 is a decent plain. It’s flying, and it’s as comfortable as a Economy class can be. What blew me away was the entertainment system. Let me break this down.

As an airline customer, I want to be able to watch the movies on board, so my time on the boring flight could go faster.

Does this user story sounds too much to ask for? Nope, I think it’s a decent business case. As a customer “trapped” on board for more than a couple of hours, constrained in movement and in general ability to do what he/she wants, should be able at least to freely select a movie to watch from a limited list that is provided. Not in this case.

First, the whole entertainment system crashed twice! ~~(I apologize for not using my own image I took with my phone – the battery died on me and I wisely forgot the USB charger:)~~.

Was that an end? Nope.

Second, when the system finally came back – any selected movie would yield “The selected content is not available at this moment”. Awesome work folks. Just what a client needs.

Good that some people are hacky enough to go into flight information (crappy video with status of the flight) and at that time start zipping channels on the armrest (on the right side). That, surprisingly, was able to flip through the channels where movies were playing in an endless loop. Ha! Some entertainment, ladies and gentlemen.

Moral of the story – quality is just not there. To understand if your software is worth anything, become the client of your own software. Being techy is not enough. UX and usability are as important as the software itself. Bring value and not shame on our profession – that’s one of the things I realize in encounters like this.

PS: Talking about usability – same entertainment system, the volume buttons seemed to be switched. Louder button was on left, and quieter button was on right… weird :)

Once You Have Tasted Flight, You Will Walk the Earth With Your Eyes Turned Skywards

Sean Feldman — Sat, 13 Jun 2009 14:52:00 GMT

Today, my friend Ran (no blog – boo!), has gave me a chance to feel what it is like to fly. Unfortunately, the weather conditions were not the best, and we could not do a lot, but the time spent up there was awesome. Feels great, and I wish I could do it more. Who knows, maybe I am discovering a new hobby in exploring the Z dimension :) Either way, a few pictures worth a long blog post.

PS: When we were about to leave, another flying craft appeared, “showing off” some nice stunts. As I learned later, it was a retired F-15 pilot. Another guy showed up as well, not flying, but getting his plain in the air. Hobby that is an obsession.

Stealing Rans' signature borrowed from Leonard Da Vinci I will finish this. "For once you have tasted flight you will walk the earth with your eyes turned skywards, for there you have been and there you will long to return."

With Power Comes Responsibility

Sean Feldman — Fri, 12 Jun 2009 17:20:00 GMT

In software like in a real life, not always everything can be extremely simple. One example I can think of right away is Inversion of Control container (IoC). In a simple application, it’s not a big deal, and normally achieved easily. The dependent component leverages some sort of Static Gateway container to resolve the dependencies based on contacts.

        1: public class Component

       2: {

       3:     public Component(IDependency dependency) //...

       4:     public Component() : this(DependencyResolver.Resolve<IDependency>()) //...

       5: }

In order to “populate” container with all the dependencies, normally we’d leverage some sort of start-up task to achieve the goal.

   1: public class StartupTask : ICommand

   2: {

   3:     public void Execute()

   4:     {

   5:         DependencyResolver.Register<IDependency>(() => new Dependency());

   6:     }

   7: }

When does the complexity creeps in? When a real life scenario kicks in. One of those scenarios are services. Why services? Because now it’s no longer a linear execution (a service can be started and stopped), and we neither want to pollute the service code with start-up tasks’ responsibilities. Solution? Different ones, but either way, a bit of complexity is added and from that moment and on developers are required to “ramp up” in knowledge to be able to understand and maintain it (develop or just-keep-alive). This is where “with power comes responsibility” is mostly used.

So is happening in real life. I was quiet surprised to see the most unexpected place – kids playground.

Playgrounds in Israel are mostly for kids up to age of 6 and not extremely attractive for teens. Despite unmatched age, those normally spend some time at playgrounds as well, ruining them completely. A bright idea that a wise man had was to introduce “work-out” machines side-by-side with kids playground, so teens would invest their energy in a more peaceful way. Boy it worked! Not only little kids now have playgrounds in normal and usable condition and their parents a peace of mind, but also the awareness among teenagers for physical fitness has significantly raised. Well done. Here are some shots of proof how with power comes responsibility.

Calgary, June 6th 2009

Sean Feldman — Sat, 06 Jun 2009 14:49:00 GMT

I am about to leave for my vacation and I think it is a perfect timing, based on what I saw this morning outside :)

TortoiseSVN – Missing Key Shortcuts

Sean Feldman — Tue, 02 Jun 2009 14:24:00 GMT

Update: 2009-06-03

TortoiseSVN is a good tool. I like the frequent updates and good integration with Visual Studio through VisualSVN. What I find annoying, is breaking changes with no immediate follow-ups to fix those. Now it’s the missing key shortcuts. I prefer keyboard to a mouse, so in my case it’s a waste.

Please bring it back.

MIME Header - Content-Disposition

Sean Feldman — Tue, 02 Jun 2009 05:17:00 GMT

I am trying to figure out something on MIME header, and just can’t understand who is standing behind the RFCs. Are they trying to read it on their own and realize if it makes sense?!

The problem I am facing is attachments in another standard, RosettaNet, that is leveraging MIME for attachments. We are using a third party component to parse a RosettaNet message and load all the attachments. Attachments original filenames are supposed to be in the “Content-Disposition” property, marked as “Content-Disposition: attachment; filename=some_filename” according to the this WIKI. “But WIKI is not RFC” you say, well, read RFC 2183. It says

In addition to allowing the sender to specify the presentational
disposition of a message component, it is desirable to allow her to
indicate a default archival disposition; a filename. The optional
"filename" parameter provides for this.

And later:

2.3  The Filename Parameter

   The sender may want to suggest a filename to be used if the entity is
   detached and stored in a separate file. If the receiving MUA writes
   the entity to a file, the suggested filename should be used as a
   basis for the actual filename, where possible.

Reading more of the great RFC, I found an example #3, in section 2.10

The following body part contains a JPEG image that should be
displayed to the user only if the user requests it. If the JPEG is
written to a file, the file should be named "genome.jpg".  The
recipient's user might also choose to set the last-modified date of
the stored file to date in the modification-date parameter:

        Content-Type: image/jpeg
        Content-Disposition: attachment; filename=genome.jpeg;
          modification-date="Wed, 12 Feb 1997 16:29:51 -0500";
        Content-Description: a complete map of the human genome

        <jpeg data>

I am really confused. One part says “it’s optional”, the other part says “should be used”. So in case I want to save the attachment in a file with the original filename, I might end up not having one (filename)?! Great… Long live standards.

Wise Manager Words

Sean Feldman — Wed, 27 May 2009 23:52:00 GMT

The task then is to refine the code base to better meet customer needs. If that is not clear, the programmers should not write a line of code. Every line of code costs money to write and more money to support. It is better for the developers to be surfing than writing code that won’t be needed. If they write code that ultimately is not used, I will be paying for that code for the life of the system, which is typically longer than my professional life. If they went surfing, they would have fun, and I would have a less expensive system and fewer headaches to maintain.

-- Jeff Sutherland

NHibernate SessionFactory Lesson

Sean Feldman — Thu, 21 May 2009 05:22:00 GMT

Anyone who worked with NHibernate knows that SessionFactory is an expensive object, that better to be constructed once, cached and re-used to build lightweight and disposable NHibernate sessions. It’s always shows up as a warning in books (NHibernate in Action, page 35), WIKIs, blogs, etc.

Today our team had a chance to experience what a wrong handling of SessionFactory can turn into – a huge memory leak. SessionFactory is a heavy object, it’s initialization and allocation is not a trivial one. Each time SessionFactory is constructed, it uses a significant amount of recourses and holds to those. If SessionFactory is not cached as a single instance, each allocation causes to the overall memory leak. Combine that with luck of Session disposing generates a very interesting result – more than a gig of memory for something that is barely 20 megs.

Moral of the story:

- As in pair programming, so is in pair-troubleshooting – team works better

- Using a third party components (even the best out there) without exploratory tests will cause eventually pain

- Follow simple notes third party components authors write, they might simplify your life

Building a Dream Team

Sean Feldman — Tue, 19 May 2009 16:57:00 GMT

The company I work for, Cortex Business Solutions, is in the hiring mode again. We are looking for passionate developers (Terry has worded the requirements in his post already, so I will keep it DRY).