Read my latest article: 8 things I look for in a Ruby on Rails app (posted Thu, 06 Jul 2017 16:59:00 GMT)

20 articles on Cucumber and a free beverage recipe!

Posted by Fri, 10 Apr 2009 02:22:00 GMT

Cucumber has been getting quite a bit of attention in the community and with the new RSpec Book on nearing publication, I predict that by this time next year, it’ll become a household word like boanthropy.

What is Cucumber?

The Cucumber project describes itself as a suite that, “lets software development teams describe how software should behave in plain text. The text is written in a business-readable domain-specific language and serves as documentation, automated tests and development-aid – all rolled into one format.

One of the great things about Cucumber is that it can be used to test applications in any language. I haven’t been able to track down a lot of articles of how people are using it with other languages, so please comment if you’re aware of some.

In any event, I’ve been collecting and reading resources from a variety of Cucumber aficionados and thought I’d share some links with you. To round it out, I asked on twitter for some others so that I could hit twenty. :-)

  1. What’s in a Story?, Dan North
  2. Telling a good story – Rspec stories from the trenches, Joseph Wilk
  3. Beginning with Cucumber, Ryan Bates (Railscasts)
  4. Using RSpec, Cucumber and User stories to build our internal systems, Rahoul Baruah
  5. Cucumber: The Latest in Ruby Testing, Ruby Inside
  6. Using Cucumber for Acceptance Testing, Noel Rappin
  7. Behavior Driven Development with Cucumber, Brandon Keepers (presentation/slides)
  8. Testing capistrano recipes with cucumber, Jeff Dean
  9. Using Cucumber to Integrate Distributed Systems and Test Messaging, Ben Mabey
  10. Tutorial: How to install/setup Cucumber, Alan Mitchell
  11. Testing outbound emails with Cucumber, Dr. Nic Willians
  12. Proper Cucumber Sintatra Driving, Chris Strom
  13. On getting started using Cucumber for .NET
  14. DRY up your Cucumber Steps, Matt Wynne
  15. Cucumber, Celerity, & FireWatir, Aidy Lewis (presentation/video)
  16. Cucumber step definition tip: Stubbing time, Bryan Helmkamp
  17. Story Driven Development Recipes with Cucumber, Sebastien Auvray
  18. Testing Facebook with Cucumber, Brandon Keepers
  19. Testing with the help of machinist, forgery, cucumber, webrat and rspec, Etienne van Tonder
  20. Integration testing SSL with Cucumber
  21. Continuous Integration Blueprints: How to Build an Army of Killer Robots With Hudson and Cucumber

So.. there you have it. Please post comments with links to any useful articles not mentioned and I’ll try to keep the list updated.

Also, be sure to check out the list of tutorials and related blog posts on the cucumber wiki (github).

FREE RECIPE: Cucumber Water

And now…for the reason you are all here! If you like cucumbers (eating them)... I would highly recommend heading to your local farmers market and purchasing some cucumbers. Aside from being healthy to eat… they can help make a tasty beverage.

Then do the following…

  • Chop several slices of a cucumber
  • Fill a pitcher with cold water and ice
  • Toss in slices of cucumber
  • Stir and leave in fridge for a while
  • Take out of fridge, pour into cup…
  • Drink… hack… and enjoy

Be sure to check out, How to Make Cucumber Water on wikihow for details.

Happy Hacking!

Related Posts (by me)

BDD is still kinky

Posted by Tue, 10 Apr 2007 20:51:00 GMT

Embracing Failure, part 1

Posted by Tue, 10 Apr 2007 20:38:00 GMT

I’m currently reading To Engineer is Human, by Henry Petroski and found the following applicable to software development and managing client and customer expectations.

“As much as it is human to make mistakes, it is also human to want to avoid them. Murphy’s Law, holding that anything that can go wrong will, is not a law of nature but a joke. All the light bulbs that last until we tire of the lamp, all the shoelaces that outlast their shoes, all the automobiles that give trouble-free service until they are traded in have the last laugh on Murphy. Just as he will not outlive his law, so nothing manufactured can be or is expected to last forever. Once we recognize this elementary fact, the possibility of a machine or a building being as near to perfect for its designed lifetime as its creators may strive to be for theirs is not only a realistic goal but also a reasonable expectation for consumers. It is only when we set ourselves such an unrealistic goal as buying a shoelace that will never break, inventing a perpetual motion machine, or building a vehicle that will never break down that we appear to be fools and not rational beings.”

I’m sure that most of us are guilty of having high expectations for products that we purchased. (why does my ipod screen scratch so easily when in my pocket?) We also set high expectations for the code that we develop, which is why we (hopefully) continue to refine our process. We’re bound to time and budget constraints, which often prevent us from testing every imaginable edge case. Given our constraints, problems are almost always going to arise. It’s no wonder that we see Test-Driven Development as an important part of a healthy development process. We want to catch our failures as early as possible.

Our clients often have high expectations and it’s almost always very reasonable. That’s not to say that some clients will not have highly irrational expectations. It’s our job to manage these expectations as best as possible.

Do we mislead our clients by convincing them that our TDD/BDD process is going to prevent any bugs from creeping from the woodwork after the development cycle is finished?

“I thought that we paid you to fully test the code?”

Really… is that even possible? Can we predict (and test) every possible interaction within an application? Highly unlikely.

What we can do is plan for and embrace failure. We can help our clients understand that almost every application needs to be maintained after it’s initial development cycle. Bugs are inevitable and there needs to be a clear process for handling them.

Perhaps I’m abusing the bug fixing process by calling it a failure… but I’ve also found that yes… many bugs are due to failure. Whether that be a failure to specify application behavior, a failure to understand the project goals, a failure in communication, ...or maybe a failure in our software architecture. We’re constantly failing.. and it’s okay!

IT’S OKAY TO FAIL! (some of the time…)

“No one wants to learn by mistakes, but we cannot learn enough from successes to go beyond the state of the art. Contrary to their popular characterization as intellectual conservatives, engineers are really among the avant-garde. They are constantly seeking to employ new concepts to reduce the weigh and thus the cost of their structures, and they are constantly striving to do more with less so the resulting structure represents an efficient use of materials. The engineer always believes he is trying something without error, but the truth of the matter is that each new structure can be a new trial. In the meantime the layman, whose spokesman is often a poet or writer, can be threatened by both the failures and the successes. Such is the nature not only of science and engineering, but of all human endeavors.”

As we’re creating these virtual structures… are we really taking the time to reflect on our failures? This is why some teams adopt practices like iteration retrospectives and post-mortems.

I’ll end this with a few questions, which I hope that you’ll share your experiences about…

  • In what ways is your team embracing the failures of your development projects?
  • How do you help manage your clients expectations… so that they too can plan for and embrace failure? Isn’t their new business venture on the web… likely to experience some failure?

We have so much to learn…

Is BDD kinkier than TDD?

Posted by Thu, 08 Feb 2007 18:20:00 GMT

If you’re in need of a compelling reason to switch from Test-Driven Development to Behavior-Driven Development... consider this.

“BDD sounds kinkier.” -Michael K. Loukides, Book Editor for O’Reilly

...on that bombshell... I am going to suggest that this be used as the official BDD logo.

There you have it. Deep down… the biggest reason that I switched from Test::Unit to RSpec... was the sex appeal. ;-)

What was your reason?

Keeping the Code Organic

Posted by Sun, 30 Oct 2005 00:30:00 GMT

The landscape around us is quickly changing-really, it has been changing for some time now-we’ve come a point where we admit that it’s okay to want more for less. We want more features, in less time. We want more control, for less money. Why? When did we collectively decide that huge monolithic systems could be completed in a fraction of the time it should take?

After years of working in .NET, PHP, Perl, and even a little Python, I have gone down the road of simplicity. I want simple looking code (thank you Ruby). Code that I can hand off to another developer and for them to simply get it—which helps to keep things moving. It’s about getting the project done.

Scenario: The client wants delivery in X days, so you aim for Y days early. Shortcuts get made, tests are forgotten, code is blemished, and deadlines still manage to sneak by unmet. Why do we do this to ourselves?

I say, no more!

Sacrifices Are Okay

What? You mean I can choose to leave something out? I can-dare, I say-tell my client no? Yes! Well, maybe. It’s time to re-think how you view your projects. Have you asked your client, “What is the single-most-important feature of this project?” Every project has one. Your customer will likely be relieved to hear that you care about the purpose of the project. And it gives you an idea as to where not to make sacrifices, which in turn helps to identify the areas where you can.

So, if you haven’t asked them yet… ask them now.

The Big Picture

If things change, how will it impact your timeframe? When your schedule is threatened, it becomes easier to see what isn’t necessary, or perhaps, not necessary right now.

All features in a project are part of the big pictures. If you ask your client what is required they will almost always respond with the all to easy, “everything.” Simply accepting this as fact often leads to shoddy workmanship in favor of giving your client “everything.” To the client it may seem like you aced the test, but that’s because they don’t know you’ve cheated. I’m sure a lot of you know what it’s like to inherit the code of someone who has done this, and you know you’ve probably been on the other end as well.

A Neverending Story

Projects aren’t just instantly created, they evolve. They need to be fine-tuned, maintained and should most certainly be refactored when necessary. Most projects require ongoing work… because requirements do change.

It’s time to stop and really consider how you approach both your clients and their projects. Can the next project be built in an evolutionary fashion? Can you focus on one new feature at a time, maintaining your tests, and avoiding bloat?

“Big fleas have little fleas Upon their backs to bite ‘em: Little fleas have lesser fleas And so ad infinitum.”

I found this in a book that I picked up at the local Library booksale for something like 20 cents. The book, The New Utopians by, Robert Boguslaw was written in 1965 and has some insightful thoughts on systems as organisms.

Keep it Organic

Pesticides are not necesary to produce quality produce. They are a cheap shortcut that can cause other problems in the longrun, and are generally not a healthy addition to the lifecycle of the fruit or vegetable (or to those who harvest it and consume it).

Test-Driven Development allows you to constantly monitor the behavior of your application. Feature-Driven Development keeps your team focused on what is currently the most important piece of your project. Don’t rely on pesticide, let the project flow the way it wants to.

Keep it Flexible

Business Rules should not be flexible… but they should. That sounds confusing, but it’s not. Know where to make that distinction. Add your rules first… build your tests… then code. Maintain flexibility through your rules.

Test First. Code Second. Lather. Rinse. Repeat.

Be Proud of Your Code, But Not Blinded By It

You’re biased. Your code is biased. The opinion that you have about your code is biased. You are proud of your code… but you can do it better and some people are better at somethings than you are. Don’t dwell on it, embrace it.

How many of you are making the mistake of being the only programmer on a project? I’m not a big fan of big teams, but I know that small and focused teams are extremly productive and better positioned for the big projects of tomorrow. Find someone that you trust and trade peer-review time. Not sure where to start? Pick up a copy of Refactoring. It’s time that you RE-think how you are doing things.

Embrace Heuristics

It’s time to challenge yourself. A new year is almost upon us and we’re all behind on our goals… because things change. This is the time to explore your possibilities. Learn something new. Don’t be afraid to break things. Just learn why the thing broke. Learn to be a good tester. Learn to write cleaner code. Learn to refactor your code. Learn to make it readable.

Learn to learn… and remember to buy organic. ;-)