Automation with Puffin

In Part 1 of this series, Keyton introduced his Puffin framework and showed how it helps you automate (potentially interrelated) HTTP calls in order to test a dynamic Web application. Since that article appeared, Keyton has redesigned and expanded the core engine. The latest version of the Puffin framework now allows you to automate a wider variety of actions including Web, file, database, socket, and command line (along with custom actions that are a simple framework extension away). With these latest improvements, you can now use Puffin (renamed the Puffin Automation Framework) for not only Web application testing but also system monitoring and data transfer automation. This article introduces the key concepts behind the system's architectural improvements and discusses its newly extended use.

Introduction

You may wonder why I changed the focus of the Puffin framework. After all, Web testing alone is a worthy goal. Why did I expand Puffin's initial target problem space instead of shrink it? Answering this questions reflects some of the key features (both pros and cons) of open source development.

I started developing Puffin to meet a personal need: I had a very complex, XML-based application that I needed to test. The commercial solutions available to me were either expensive or inadequate, so I decided to solve my own problem. As for making it open source, this was an easy decision. I work with a team that has managed to solve its complex technical problems and reduce operating expenses by about 50% -- all with the help of open source solutions. If I can somehow "give back" to those open source developers who helped me, I want to do so.

So I built the initial Puffin Web Testing Framework. As you may recall from Part 1, this framework allows you to script a series of calls to a Web application, validating the results from each action and using outputs from one action as the inputs for subsequent actions. In that article we installed and configured the system and ran a simple test plan script.

People had already begun using the system at that time, but the developerWorks article increased its rate of adoption. Many users began to ask for features and functions that were outside the realm of Web application testing. Most users were doing system monitoring, and others were using Puffin to automate batch processes in which data from one (typically legacy) system was being retrieved, validated, possibly converted, and used to update a second system where it was validated again. So I began to look at Puffin as a way to help with these other problems.

At about this same time, I began speaking with some people from Webware (see Resources later in this article) about testing in general. The Webware folks' biggest request was to be able to extend Puffin in Python. They wanted to take the framework and leverage it. Some of them wanted to do this because they are Pythoneers of the finest caliber. Some wanted to do this because they didn't care for XML. Others just wanted it in principle.

I wanted to serve as many Puffin users as I could. I wanted to allow for extension at the code level for those folks who wanted it. I wanted to allow for an XML-only interface for those people who don't use Python. And I wanted to help solve the varied problems for which Puffin was being used.

Unfortunately, the initial architecture just didn't allow for it. So I redesigned the core product, which meant looking at how Puffin works at the processing engine level. Understanding Puffin from this perspective gives a good understanding for how it works and how it might help you in the above mentioned problem spaces and others not yet considered.

This article introduces the core processing engine of Puffin. In future articles we'll cover how to use Puffin in complex Web application testing, system monitoring, and data transfer automation.