"Terminal junkies rejoice! Now you can use Cucumber to test your command line interfaces just like you do for your web apps.…"

"Work out which bits of the system you know least about. Create the scenarios and have conversations around those bits of the system. You don’t have to grow the system from the beginning – you can pick any point you like! Which bits of the system make you most uncomfortable? Which bits make your stakeholders most uncomfortable?"

"So where does this gulf of experiences come from, why is cucumber loved by some and hated by others. At the risk of over-generalisation and mischaracterisation I recently came up with a theory: the cucumber detractors are not using cuke the way it was intended."

"Behavior-Driven Development (BDD) is a specification technique that automatically certifies that all functional requirements are treated properly by source code, through the connection of the textual description of these requirements to automated tests. Given that in some areas, in special Enterprise Information Systems, requirements are identified by Business Process Modeling - which uses graphical notations of the underlying business processes, this paper aims to provide a mapping from the basic constructs that form the most common BPM languages to Behavior Driven Development constructs."

"UK-based super hacker and long time Cucumber contributor Rob Holland announced iCuke yesterday. iCuke is a Cucumber extension that lets you write automated functional tests for iPhone apps. Here is a little teaser…"

"Minimalist acceptance testing on top of RSpec"

"CannedCukes is all about one thing: helping people make better BDD tests. CannedCukes is a place where BDD testers from across the world can upload Cucumber features and scenarios and share them with other testers."

"After a year using RSpec, I’m happy to share “(My) RSpec Best Practices and Tips”. Let’s make your specs easier to maintain, less verbose, more structured and covering more cases!"

"Imagine the scene. You are eleven years old, and in the five minutes before the end of the lesson, your Maths teacher decides he should make his class more "fun" by introducing a "game". He explains that he is going to point at each pupil in turn and ask them to say the next number in sequence, starting from one. The "fun" part is that if the number is divisible by three, you instead say "Fizz" and if it is divisible by five you say "Buzz". So now your maths teacher is pointing at all of your classmates in turn, and they happily shout "one!", "two!", "Fizz!", "four!", "Buzz!"... until he very deliberately points at you, fixing you with a steely gaze... time stands still, your mouth dries up, your palms become sweatier and sweatier until you finally manage to croak "Fizz!". Doom is avoided, and the pointing finger moves on. Until the next time."

"I am fairly obsessive about deleting prototype code. The code that I produced might be fine, it might not. It is more than likely that it is not great because I was learning something new and making mistakes along the way. I do not want to be in a position to be building on crap code. I alway build on the simplest thing that can possibly work. The only way to be sure of that (that I know of) is BDD."

"There are some technical stories, though, which really do deliver something the business care about. You can find this out by asking, “Who cares if I don’t do this? Who cares if I don’t have an automated build? If I don’t write unit tests? If I don’t write acceptance tests?”

This is where the feature injection comes in. I’m flexing Chris Matts’s template a bit to do this; here’s how mine reads:

In order to

will need ."

"Recently here at Webbynode we had a demand for validating HTML without going as far as driving a browser. We have an internal library that generates HTML after compiling HAML templates. To fulfill our BDD needs, we wanted a simple, straightforward way to validate HTML tags without the need of a full blown browser driving engine, since we don’t have an HTTP server running while testing this library."

"Are you familiar with RSpec, new to Sinatra, and can’t get the two to cooperate? This article maybe of use to you. Alternatively, if you’re like me and you’re simply new to this universe all together, this article can certainly be of use."

"I left off last night moving into the guts of the application. The plan was to start BDDing with RSpec. It occurred to me, however, that I had no idea how to do it. Happily, Sinatra's testing documentation includes RSpec information."

"Synchronize user stories in Pivotal Tracker with Cucumber features."

"How do you name step files? What to put in each step? What not to put in steps? Here are some guidelines that will lead to better scenarios. If you are new to steps and the general syntax, please read Feature Introduction first."

"FakeWeb is a helper for faking web requests in Ruby. It works at a global level, without modifying code or writing extensive stubs."

"Variation: Saboteur
A Test Stub that is used to inject invalid indirect inputs into the SUT is often called a "Saboteur" because its purpose is to derail whatever the SUT is trying to do so we can see how the SUT copes with these circumstances. The "derailment" can be caused by returning unexpected values or objects, or it can be caused by raising an exception or causing a runtime error. Each test may either be a Simple Success Test or an Expected Exception Test (see Test Method) depending on how the SUT is expected to behave in response to the indirect input."

"RR (Double Ruby) is a test double framework that features a rich selection of double techniques and a terse syntax."

"RSpec, Cucumber, Webrat, RCov and Autotest are a powerful combination of tools for testing your Rails app. Unfortunately getting them to all work nicely together can be a bit of challenge. I recently configured a development environment from scratch on OS X 10.5 Leopard and kept track of all of the little details."

"Machinist generates data for the fields you don't care about, and constructs any necessary associated objects, leaving you to only specify the fields you do care about in your tests."

"My experience so far, as I explore what Cucumber can do, has been largely positive. Where I was starting with Cucumber and only a vague idea of how the user interaction would play out, writing the scenarios at the Cucumber level felt very valuable and gave the development a clear path that I wouldn't have otherwise had. That said, there is extra code being written, and it's clearly possible to get really tangled in getting the step definitions right."

"We’ve been writing a “feature” for every new client request on that project – for each user-created ticket we handle, we create a .feature file (and include the ticket number in the feature title), and write steps for that request. This means that we have acceptance tests for all new client requests on that project. This approach may seem a little strange, but it’s been helpful, and we’re very happy with it so far. We’ll likely take a different approach if we use Cucumber on a project from scratch.

Now you have no excuse if your projects aren’t doing any kind of top-down testing, so get out there and write some acceptance tests!"

"But enough of irony. Is this useful? I think it may be. You see, one of the great benefits of describing a problem as a Finite State Machine (FSM) is that you can complete the logic of the problem. That is, if you can enumerate the states and the events, then you know that the number of paths through the system is no larger than S * E. Or, rather, there are no more than S*E transitions from one state to another. More importantly, enumerating them is simply a matter of creating a transition for every combination of state and event.

One of the more persistent problems in BDD (and TDD for that matter) is knowing when you are done. That is, how do you know that you have written enough scenarios (tests). Perhaps there is some condition that you have forgotten to explore, some pathway through the system that you have not described."

An excellent talk on testing legacy code. Some great insights on how to use judicious refactoring and contingent testing. Not too Ruby-specific.

Just worth posting on the wall, is all.

Installation path works fine with PeepCode graphics and ~/.autotest script as well.

'Below is a “getting started” tutorial, a helpful autotesting plugin, and hints about a TextMate bundle for Javascript Unit Testing and a future Peepcode on Javascript Unit Testing.'

Love the example

"An interesting aside in favour of agile development techniques in general and TDD in particular is that even in this state the code is often much more robust and a much better functional fit than code developed under more traditional methods based on lar