Monday, July 30, 2012

Quick Review of The Cucumber Book from a SpecFlow perspective

This week I completed reading a new book titled The Cucumber Book: Behaviour-Driven Development for Testers and Developers by Matt Wynne and Aslak Hellesoy. Aslak is the founder of the Cucumber project (which is what SpecFlow for .NET is based on), and Matt is one of its most active developers. The 328-page book is only 20 USD if you get it through The Pragmatic Bookshelf and worth the money, even if you're an experienced SpecFlow developer/tester.


The code examples are written in Ruby, but even without any prior knowledge of Ruby, I managed to get through them quite easily. (Off-topic: It's not a language I see myself coding in anytime soon, so I must be a C-language addict).

Anyway, the first 6 chapters (Part I) are awesome. Not only do they provide a decent introduction to the concepts behind Cucumber and a detailed break down of the Gherkin language, it also provides numerous tips and tricks that should prevent you from making your efforts gone bad. Just as you can go bad with practices like TDD, there's a whole lot you can do wrong when dealing with automation scenarios based on the Gherkin language. Even after reading the Secret Ninja Cucumber Scrolls and everything there is to read on SpecFlow, I learned some valuable new lessons that sure are going to improve the work I'm doing right now.

Chapters 7-10 (Part II) are taking a deep-dive in implementing the Step Definitions using Ruby. Since I don't care about the Ruby details, I mostly browsed through these pages looking for hidden tips and tricks. If you are a .NET developer like me, I would do the same. But just make sure you read all the side-notes (the ones with a bluish background). They contain some valuable best practices.

Again, if you're a .NET developers, you can skip chapters 11, 14 to 16 and the appendixes since they are too specific to the Cucumber tool and the Ruby language. But do try to read chapters 12 (Testing a REST Service) and 13 (Adding Tests to a Legacy Application).

You might wonder why I still believe the 20 dollars are worth the money after I told you to skip so much of the book's contents. It just that those first 100 pages plus the many best practices in the remainder of it really make up for the rest of the book. Since I'll be talking about SpecFlow and WaTiN at the Dutch .NET User Group meeting on August 30st, I have been looking for some decent advice on writing proper Features and Scenarios for a while. The book delivered. Period.
For completeness, here’s the table of the contents.
  1. Why Cucumber?
  2. First Taste
  3. Gherkin Basics
  4. Step Definitions: From the Outside
  5. Expressive Scenarios
  6. When Cucumbers Go Bad
  7. Step Definitions: On the Inside
  8. Support Code
  9. Dealing with Message Queues and Asynchronous Components
  10. Databases
  11. The Cucumber Command-Line Interface
  12. Testing a REST Web Service
  13. Adding Tests to a Legacy Application
  14. Bootstrapping Rails
  15. Using Capybara to Test Ajax Web Applications
  16. Testing Command Line Applications with Aruba
PS. Did you know that SpecFlow 1.9 is eminent? Check out the preliminary release notes.

Thursday, July 26, 2012

Noticeable quotes from QCon New York

Just to be clear, I didn’t actually attend QCon New York this year. But after the experience of attending QCon San Francisco in 2010, I never forget the many great quotes you’ll find on Twitter. This time was no different.
As you can expect from somebody like Michael Feathers, he made some great quotes in his talk on Patterns of Software Change.
  • Architecture - the part of the system that you can not replace without having a different system
  • "Over-engineering = weighting a possible future too highly in design."
  • “Code Turbulance”, a name for frequently changed code
  • Anytime you manage by the numbers, instead of actually (God forbid) looking at the code a way will be found to game the numbers”, in a discussion on the uselessness of using only code metrics for judging the quality of your code base.
Looking forward to QCon San Francisco in November…

Friday, July 20, 2012

Required Reading Material for July 2012

Since I was already collecting the better articles that I read during the month for sharing with my colleagues and client’s coworkers, I might just as well share them here. Have fun reading them.

Virtual Panel: Code-to-Test Ratios, TDD and BDD 
A great discussion by the authorities on TDD, BDD and Specification By Example.

Agile Undercover: When Customers don’t Collaborate 
Contains best practices for dealing with the reality issues of a Scrum project.

What's Upcoming in jQuery 1.8, 1.9 and 2.0, and the Removal of IE6/7/8 Support.
A summary of important changes in the next versions of jQuery.

ReSharper 7: What’s Inside.
Even if you are already running the beta, it’s still worth a read.

Eventual consistency, CQRS and interaction design
An important aspect of using Event Sourcing is the Eventual Consistency aspect. This article explains that in more detail and how it affects the perception of the end-user.

The Turkish İ Problem and Why You Should Care
Illustrates the difficulties of not properly preparing an application for supporting multiple languages.

The Art of Misdirection
As can be expected from one of the best speakers in our profession, a deep insight in the hidden cost of software developments. Incidentally covers TDD as well.

Thursday, July 19, 2012

If you write an article about TDD, make sure it is correct

I spend a majority of my private time reading articles and blog posts, having discussions on Twitter, or engaging in conversations on conferences and community events. I'm realistic enough to understand that my opinions are not necessarily the truth, so I use those opportunities to challenge my own ideas and learn about solutions I would never think of myself.

I recently read an article titled Test-Driven ASP.NET MVC that, although I respect what the author is trying to convey, implies some things that I strongly believe are incorrect or are malpractices. Normally I wouldn't bother to blog about this, but because his article is published at the online MSDN Magazine, I couldn’t resist the urge to correct some things.

  • Thoroughly understand the MVC pattern. As Martin Fowler has clearly explained in his post on GUI patterns, the view doesn't manage the presentation of models, nor does it handle interactions with the users. Both are the responsibility of the controllers. They react to keyboard, mouse (and touch) input, use that information to interact with the (domain) model and then decide what view should be used to render the result. In that sense, ASP.NET MVC is reasonably faithful to the original pattern. The only big difference is that in the original MVC pattern, the controllers were directly handling user input whereas in ASP.NET MVC the controllers merely handle HTTP POSTs, GETs and PUTs.
  • Tiers are not layers. Tiers are used to represent a physical separation whereas layers represent a logical separation. You can have all layers (e.g. presentation, service, domain and data access) hosted on a single tier if you want, or you can assign them to multiple tiers. An example of that is an ASP.NET web site (the presentation layer) hosted on a front-end web server, the service, domain and data access layers hosted on a Intranet application server, and the database hosted on a dedicated database server. The other way around doesn't work like that though. If you didn't account for layering in your architecture, it might be very difficult to deploy your system in a distributed environment.
  • Keep your Visual Studio projects to a minimum. Having many projects such as the project-per-layer suggested in the article considerably slows down compiling, but also causes the startup time of the corresponding application to increase. Loading 10 small assemblies is much slower than loading one big assembly. Jeremy D. Miller mentioned this already in this post, but Patrick Smacchia, the author of NDepend, delivered some proof of if it here. Read my original post for more guidance on splitting up projects.
  • Separate test code from production code. The author recommends separating test code from production code, a good thing obviously. In fact, I would not even dare to think of polluting the production code base with test code. It might double the size of the assemblies and considerably increase the memory footprint of the application. But as usual, it is not always possible to avoid this. We sometimes have to make a method internal and allow the test projects to access those members using an [InternalsVisibleTo] assembly-level attribute. But that's an exception. What we do more often is make certain methods protected so that we can apply the Test-Specific Subclass pattern.
  • TDD is about test-first development. The article refers to the Test-Driven Development practice a few times but never explains its essential concepts such as writing tests before writing the production code, the red-green-refactor mantra and the many benefits it offers from a design and maintenance perspective. And neither does it explain what the exact meaning of a unit in unit testing is. In fact, not a single code example shows what a unit test would look like when practicing TDD in an ASP.NET MVC application. Why then call the article Test-Driven ASP.NET MVC. This is even more surprising considering that the author is using Jeremy D. Miller's StructureMap, somebody who has been one of the most noticeable TDD advocates in the community. I wonder whether the author really understands TDD at all.
  • Use Fakes with caution. This is also amplified by his apparent nonchalant use of Visual Studio 2012's support for generating fakes from any class. If you're practicing TDD, you’ll explicitly design the interface of your API or type and think about its dependencies. IMHO, this is an essential part of the thought process involved in TDD. Using a brute-force tool like Fakes or TypeMock Isolator allows you to ignore that part of the process and just generate whatever is needed for your test. I'm not saying Fakes or TypeMock are bad products, but because of their unique capabilities compared to popular mocking frameworks like Moq, Nsubstitue or my own favorite, FakeItEasy, I'm afraid many people will follow the author's example.
  • Dependency injection is not the same as the inversion of control principle. I hate it when developers use the terms Dependency Injection and Inversion-of-Control interchangeably. They are two different things and if you don't understand that, make sure you thoroughly read the chapter on the Dependency Inversion Principle in Pablo's SOLID guidelines. Although subtlety different, Inversion-of-control is essentially about removing the direct dependencies of one class to another out of that class and providing an abstraction that that class relies on. The inversion in this principle is about moving the responsibility for hooking up the original class with a concrete implementation of that abstraction to a 3rd party, typically an IoC framework. This will improve your chances for loose coupling, better testability, and increased maintainability on the long run. Obviously you don't have to use a DI framework, but if you do it correctly you can gain a lot of benefits from it. I myself heavily rely on Autofac after having used Microsoft Unity for a few years. And remember, just like any principle or tool, use it with caution. Overusing IoC can result in systems were it is difficult to understand what happens.
  • Resolving dependencies from inside a class completely defies the ideas behind DI. Why in the world would you suggest people to use an DI framework like StructureMap and then use a static class to resolve dependencies from within the dependent class? That vaporizes the entire purpose of a DI framework. It's not for nothing that Jeremy D. Miller wrote a post on Push, Don't Pull. Even better, that's why the word injection is in Dependency Injection! That is also why the author suggest registering a fake object in his IoC container. This is clearly a design smell resulting from his apparent incorrect understanding of the IoC principle.
  • One more issue. In the discussion on namespaces and test code, the author suggested to use the name Test (singular) in the project name. Since the namespaces in projects should use the project name as their base, you end-up with the name of something that could be the name of a class. That has been a violation of the Microsoft Design Guidelines and FxCop naming rules since the inception of the .NET Framework. I usually use the name Tests, Testing or Specs for the project that holds the unit and integration tests.

Anyway, the morale of this post is that you should get your facts straight before you write an article that is going to reach so many people. And now that I think of it, why didn't somebody from the MSDN Magazine's staff check this article in the first place? I might be wrong as well, so if disagree let me know by commenting on this post or by pinging me through my twitter handle at ddoomen.