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

"This paper introduces the theory and practice of formal verification of self-assembling systems. We interpret a well-studied abstraction of nanomolecular self assembly, the Abstract Tile Assembly Model (aTAM), into Computation Tree Logic (CTL), a temporal logic often used in model checking. We then consider the class of "rectilinear" tile assembly systems. This class includes most aTAM systems studied in the theoretical literature, and all (algorithmic) DNA tile self-assembling systems that have been realized in laboratories to date. We present a polynomial-time algorithm that, given a tile assembly system T as input, either provides a counterexample to T's rectilinearity or verifies whether T has a unique terminal assembly. …"

"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…"

"Yesterday I started using two services, UserTesting.com and fivesecondtest.com, that bring the same capital- and time-efficiency to UI design that open source tools brought to programming. Rather than work extremely hard getting the design right, then failing if you guess wrong, it is now quick and cheap to iterate. Have a crazy idea? Test it. Three alternatives? Test them."

"If we think about tests as by-products of the development process, this investment is very hard to justify because it doesn’t give direct value to any of the project stakeholders. The stakeholders of the framework, however, aren’t the customers or the business users. They are the members of the development teams (and maintenance teams if separate). Many teams I interviewed have at some point ripped out the heart of their system and replaced it, or rewritten the entire system, while keeping their acceptance tests and using them to guide the whole effort. This is where the investment in live documentation really pays off. Such a framework is genuinely a separate product, with a different lifecycle and a different group of stakeholders."

"Minimalist acceptance testing on top of RSpec"

"Noticing the pain as soon as possible and then fixing the problem - whether it is a rigid design, fragile tests or something else - requires skill. Not everybody is alert to the pain, but instead they keep on writing bad code until making changes becomes too expensive and a rewrite is needed. Not everybody fixes the problem when they feel the pain, but instead they implement a quick hack and leave an even bigger mess for the next developer. But for those who have the necessary skills and discipline, TDD can be a powerful tool and they can use it to write better code."

"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!"

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

"Metric Fu is a compilation of several tools to help find areas of code that could be improved. In this episode I show you how to setup this tool on the railscasts.com source code."

"Things to keep in mind.

No matter where you start, start with one simple test. One assertion, if you can manage it.
Write the code to make that test pass
Then refactor -- this part is critical, this is where the creative design is with a TDD process.
Then write the next test.
In Rails, you'll often start in the controller then realize that code needs to be written in the model (or vice-versa). Write a separate test for the model -- testing models from the controller makes it hard to test all the model logic.
It's okay to plan the tests in advance, but you should only work on one test at a time. (Sometimes I'll write the series of tests, then comment out all but one)"

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

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

"So what should Alex do? Continuously deploy. Every commit should be instantly deployed to production. Let’s walk through her story again, assuming she had such an ideal implementation of Continuous Deployment.
Alex commits. Minutes later warnings go off that the cluster is no longer healthy. The failure is easily correlated to Alex’s change and her change is reverted. Alex spends minimal time debugging, finding the now obvious typo with ease. Her changes still caused a failure cascade, but the downtime was minimal. "

"Assuming you're with me so far, what will that mean in practice? Throwing out a lot of code. That's because as you get better at continuous deployment, you learn more and more about what works and what doesn't. If you're serious about learning, you'll continuously learn to prune the dead weight that doesn't work. That's not entirely without risk, which is a lesson we learned all-too-well at IMVU. Luckily, Chad Austin has recently weighed in with an excellent piece called 10 Pitfalls of Dirty Code."

"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!"

Also may be useful in biology and biochemistry, amazingly enough.

Just worth posting on the wall, is all.

Useful starting point for my acceptance testing list. Noted PPV report, which is a real acceptance test based on subjective estimates; could that be fleshed out?

via rfrank at the Distributed Proofreaders community

"In the beginning, the Product Owner identified a Need. And the Need was without form, and void; and darkness was upon the face of the deep. And the Spirit of the Team (Team) moved upon the face of the Need and asked some questions."

Historical market data source.

New version of NUnit testing framework is released.

Learning by doing the wrong thing