There is a new kid on the block, Behavior Driven Development, or BDD, so naturally I rushed to check it out. I immediately came across Cucumber, a BDD testing framework for Ruby. The Cucumber site is fairly informative and you pretty much immediately understand that Cucumber is about writing "Given->When->Then" test cases (or as they are called Scenarios). Unlike other test frameworks, developer can really "talk" to Cucumber. You can start implementing a simple use case as follows:

Given that a user arrives to any page
When no session exists
Then user is redirected to Login page

Sounds pretty straight forward - one of the pros of using Cucumber is that your test scenarios are pretty much self-documenting. Once you write this scenario, you start executing it in Cucumber which will keep failing until it succeeds. When you will run it the first time, Cucumber will not understand any of this. As you keep going, you will have to define "that a user arrives to" in Cucumber in order for the first step to pass. Then you will have to define "no session exists", and then "user is redirected to". So gradually you will be explaining to Cucumber what it is that your test case is doing.

My initial impression was that this is way too cool. Looking from the outside, you can basically read the code in plain English which simplifies readability and understanding of what it is you are testing. But once I started looking at it a bit deeper, it occurred to me that testing this way on a serious project can be really dangerous. Here is why.

Cucumber Imposes Endless DSLs
This comment may go towards BDD in general. Basically Cucumber allows you to create an endless Domain Specific Language (DSL) for your tests. Any new or existing developer can just "speak" his mind to Cucumber which will inevitably lead to more and more new "key phrases" for the overall DSL. In my view this may significantly hinder reusability of test cases and pretty soon you may end up in a position where you have thousands upon thousands of unmaintainable Cucumber scenarios. If you look at GridGain test cases for example (and we have about a thousand of test cases), we managed to keep them very concise only because they are mostly reusing existing test components available to them. One may argue that you can do the same in Cucumber, but this would be against overall Cucumber philosophy in my view.

Enterprises Need Structure
Yes, enterprise projects need structure and developers need to be constrained by available libraries and APIs. You cannot just let every developer go willy-nilly by allowing him to "talk freely" to the underlying testing framework. I have nothing against a specific DSL for testing (on the contrary, I would encourage it), but this DSL should be well defined and used by everyone in the company.

I should mention, however, that on a relatively small project, testing the Cucumber way may be very productive. Since small projects are exactly the sweet spot for Ruby, Cucumber may very well be the best testing framework available for Ruby. But as the project will grow, using Cucumber will become more and more painful and unmaintainable.

So, here is the test scenario for GridGain that you could create in Cucumber (forgive the sarcasm, but I couldn't resist):

Given that GridGain is a large enterprise project
When I write test scenarios in Cucumber
Then I will shoot myself in the foot

P.S. I realize that this post may stir some disapproval from Cucumber community. In the interest of full disclosure I want to mention that I have not used Cucumber on a real project and simply am expressing my opinion here which is not based on actual project experience.

 

I just came across a pretty old blog about GridGain where a user explained his experiences with GridGain and had a brief Q&A via comments.

When asked about difference between GridGain and Globus I think he gave a spot-on answer:

"No, I’ve never worked with the Globus Toolkit. From what I’ve read, Globus is more about collaboration of organizations (forming "virtual organizations") and solving all the problems that come with it like interoperability and security concerns.

GridGain on the other hand has a strong focus on simplicity and developer usability. I think it’s perfect for "local" grids with perhaps a few dozens (or hundreds?) of nodes. You can certainly build a more comprehensive solution on top of GridGain, but the local computational grid use case is where it is best suited at the moment.

In my concrete case at work we’ve got a highly secured internal network and need a convenient solution for distributing the workload to boost throughput. Globus looks like overkill, but I’m confident that GridGain is the right thing for us."

Although this conversation took place about 2 years ago and GridGain had since evolved into a Cloud Development Platform with aplenty of new features, our (quoting) "strong focus on simplicity and developer usability" has not changed. Even with such features in the pipeline as data grid and hands-free self-scaling on the clouds, GridGain developers will still enjoy the same simple deployment-less process:

Change -> Compile -> Run On Cloud

Take a look at some of our Online Screen Casts and find out for yourselves.