This post continues directly from Using Sequences in Lucid. In this post I want to show a bit about how sequences can be parameterized, from simple variable elements in statements all the way to the use of data tables.

With the release of 0.2.0, Lucid has the ability to use sequences as part of the test description language. In this post I’ll explain what that means and we’ll go through an example that puts this concept to use.

I periodically get asked if my Lucid solution is “agile.” The answer, of course, is no. It’s a tool. The better question is whether Lucid, as a tool solution, supports practices that are usually referred to as agile. So let’s talk about that.

This post will clearly follow on from the first part where we created a project (called tutorial-web), created a test spec, created test matchers and test definitions based on the test steps in the test spec, and we wrote a page definition.

Here I’m assuming you have followed the previous post and have a project set up and ready to go. This post will take you through using Lucid with Fluent and also talk a little bit about how you write your TDL and some of the considerations that go into that. This will be a fairly comprehensive post, attacking along a few different lines of thought.

In previous posts regarding the Lucid tool, I showed how to use it in terms of its basic execution cycle as well as how to augment that cycle by calling out to an external library. In this post I’ll show how Lucid can help people get started with the tool by having it generate a particular project structure for you.

In the previous Getting Started with Lucid series (see parts 1, 2 and 3), I gave a general idea of how to use the Lucid tool, with some broad brush strokes into the execution cycle as well as some of the options you can use to modify that cycle. Here we’ll investigate how to get Lucid to talk with another application that you want to test.

In this post I’ll continue putting Lucid through its paces. It’s definitely presumed you have gone through part 1 and part 2, since I’ll build off of the example and directory structure that we worked on. Here I want to show a few more variations of Lucid execution.

In the first post in this series I took you through some steps to use Lucid by creating the start of a test specification and seeing how that specification could be made executable. This post will continue the process, building on what was already created, but also getting into some details about the conventions Lucid uses for directories where it looks for files.

In a previous post I introduced the basics of Lucid. This post, and a few follow-ups, will be all about putting Lucid through its paces. If you have a Ruby system all set up, you just need to install the lucid gem. You can read the Setting Up Lucid instructions for more details.

I have been working on a tool called Lucid which is, in many ways, almost a direct port of the popular tool Cucumber. I do believe tools with humanizing and fluent interfaces are key to the future of testing. Here I’ll explain a little of the basis behind Lucid.