I just wanted your opinion on SLIM as opposed to standard FIT/Fitnesse. Are there things that can only be done via the FIT/Fitnesse route that cannot be done via SLIM? So for acceptance tests and integration tests can I just use SLIM?

We want to exploit the BDD abilities of Scenario tables in SLIM. Ideally I would like to use SLIM to undertake all kinds of tests. I assume it has all the same capabilities? Are there any issues?

On the face of it, SLIM seems to be the preferred way forward for new FitNesse implementations as it is being actively developed and maintained by the same folks who develop FitNesse. FIT is a bit of an orphan at the moment, Rick Mugridge and I were talking about taking over that integration and enhancing it.

In terms of features, SLIM gives you better compatibility across platforms because a lot of the test system responsibility has been taken over by FitNesse itself (parsing HTML, deciding how to interpret a table, storing and reading symbol values). Watch this video for more information about the differences in responsibilities.

On the other hand, because of the way SLIM works, fitlibrary flow-mode interaction is practically impossible. Most of my clients still use flow mode tests as that is a great way to write and maintain a very thin fixture layer for complex tests.

SLIM also allows you to use Scenario tables, as you mentioned. Scenario tables give testers a lot more power as they can script multi-step execution and compose lower level fixtures into higher level tables, without involving developers to do the same in fixtures. Depending on your environment and team, this might or might not make sense. For covering and existing system with regression tests, it probably does. For using acceptance tests as a guide for development, beware of overdoing it. I am very concerned about long-term maintenance costs of such tests. What happens in this case is that people are effectively programming with tables – doing the same in code would allow you to benefit from IDE support for refactoring, file management and all sorts of other things that make IDEs useful. You lose all that by using scenario tables in order to make testers a bit more independent. I would rather suggest training the testers some basic coding skills so that they can write fixtures.

Dave and I will discuss some of the common pitfalls faced by teams in getting to grips with Fitnesse. We will show examples of good and bad acceptance tests, illustrating how different styles of fixtures lend themselves to different types of tests. We also highlight some of the features of Fitnesse that allow you to keep your tests expressive, useful and easy to maintain.

Make this interactive and bring your own test examples to be discussed, critiqued and improved upon in a group workshop.

For more information and to register, see
http://skillsmatter.com/podcast/agile-testing/david-evans-gojko-adzic-interactive-agile-acceptance-testing-clinic

This three day workshop immerses the participants into a project driven by Specification by Example and Agile Acceptance Testing. Through facilitated exercises and discussion, you will learn how to bridge the communication gap between stakeholders and implementation teams, build quality into software from the start, design, develop and deliver systems fit for purpose.

This workshop is aimed at testers, business analysts and developers. It combines an introduction to Specification by Example and Agile Acceptance Testing, a set of exercises to help you get started with FitNesse – the most popular tool for agile acceptance testing – and a full day of working on realistic domain examples taken from your recent projects or a future phases of projects. This ensures that you gain real-world experience, enabling you to kick-start internal adoption of these practices in your team.

Click here for more information and to register.

How would you effectively define a sufficient set of If-When-Then scenarios to test for correctness what is potentially an extremely large set of transformations?

BDD scenarios (and agile acceptance tests in general) are not about full regression testing – they work best as a set of examples that demonstrate business rules which need to be developed, and as the software matures become live documentation of what the system does. So they typically should contain:

• A representative example demonstrating each important aspect of a business rule. Business users, analysts or customers will typically lead defining these.
• An example demonstrating each important technical edge case (technical boundary conditions) developers will typically suggest cases here. Business users, analysts or customers will define the correct expected behaviour.
• An example demonstrating each particularly troublesome area of the expected implementation (such as cases that caused bugs in the past, boundary conditions that might not be explicitly demonstrated by previous examples etc). Testers will typically suggest these and business users, analysts or customers will define the correct behaviour.

I would start by asking business users to define important examples, then developers and testers to comment on these examples and suggest important conditions and cases not covered by existing examples. I would do this in a specification workshop to allow everyone to benefit from a discussion and build a shared understanding of the problem. At the point where everyone is happy that they have enough information to work, we have enough examples. Then I would capture the examples discussed during the workshop, identify potential duplicates, remove information not directly related to the business rules for the cases and formalise them as acceptance tests/BDD scenarios.

This is not to say that additional examples cannot be added later to provide a more complete functional regression check. This can even be automated using the same scenario step format and automation tools and helpers as the other examples. But I like to keep the two separate so that there is a small and focused specification that can be easily read and understood later, when things change. When using tools such as FitNesse, you can link the two sets of examples with an “For Additional Examples, See …” link to point people to a full regression set later. Having them separate also allows you to quickly run the entire specification and get faster feedback.