So what is AFTER?
Well this is going to be my, and hopefully others in the community, attempt to build a robust, pluggable test engine that can handle functional UI testing. I have submitted a request to host my project at SourceForge as an Open Source project that will be licensed under the LGPL. I think this is the right license to use. Basically I want it to be free, but if others are going to modify and extend it I want that to be free too. So I will keep you posted as to the status of our hosting at SourceForge. I will also be putting up a page here on my site where it can redirect you to the SourceForge site.

So what does AFTER stand for?
Just what I hope it to be: An Automated Functional Test Engine in Ruby.

To me, and I am sure it is only me, but the problem of functional UI testing just doesn't seem to be something that should be to hard to automate. I know that there is always going be the need for exploratory testing that doesn't need to have time spent in trying to automate it because it should always be changing. But there is very common functionality that I continue to see so many duplicating in the field of testing that we should be able to do something about that.

What do I see this engine being able to do?
It will start with the basics. Load a script that will dictate to the engine what to do. All the while I want to capture performance statistics and exceptions. I also want the results to be integrated into a continuous integration system, such as CruiseControl.Net so I can have the results affect the status of my builds, which by the way I already have the XSLT files needed to integrate the results.

Other enhancements I would like to see:

1. I would like to see the scripts data driven. So one file would define the tests themselves and then other files can be used as the data for the scripts. This way we can rerun the same script multiple times with different data scenarios.
2. I would like the engine to be pluggable. Basically if you want to run your tests against an Internet Explorer browser app, Firefox browser app, xyz all that should be needed is the component libraries to facilitate the interaction with the end application. To me a test engine shouldn't care about which environment it runs against. All it should care about is managing the tests and the results.
3. If we are going totally wild I would like a simple and easy method for generating application maps. This has and always will be the hardest challenge for functional UI testing. With windows applications it is a litle easier to generate application maps as the source files are easier to parse. With browser based apps it can be tougher because of dynamic controls being generated in Javascript.

Well things are just some of the features that I hope I will be able to accomplish with this test engine.