Getting up to BAT: Building a True DSL
If you’ve made it this far with your BAT implementation, you have finally arrived.
Not to say that you’ll ever be done expanding your automation framework and building and improving your BATs, but you are at the point of having a mature usable BAT framework and you can be proud of that accomplishment.
If you truly want to see where the rabbit hole goes though… Read on
Taking it to 11
If you have designed a good automation framework for writing your BATs, you will most likely have created an internal domain specific language (DSL).
What is an internal DSL?
Basically it is a set of APIs and rules built in another language that function as their own language.
You might have some code that looks like this:
You can see how this code is really looking like a language itself. It is hard to tell if this code is even C# or Java.
This is a good example of an internal DSL.
If we were to take this same section of a BAT test and write it as an external DSL, it might look something like this:
With a true DSL we can simplify even further to get right down to the bare minimum set of commands we need to execute what we want in our application.
How to implement a DSL?
There are a number of tools and techniques that can be used to create a DSL. I’ll hit on some of those a bit later on, but first we need to design the DSL itself.
Designing a DSL can be challenging, but I have found the best approach is to use a similar approach to what we used to design our automation framework.
It is best to work backwards from the syntax that would make your BAT the easiest to write and the most clear. Once you have done that you can worry later about implementing the DSL to support the syntax you have come up with.
You should focus on creating a limited vocabulary for your DSL so that it will be easy for someone to learn and know what their options are.
The more restrictions we put into a DSL the easier that DSL becomes for doing a specific purpose.
We want to give the user of a DSL no more options than required for what they want to do and no less.
This isn’t always easy to do. It often requires some careful thought and refinement.
Your DSL should also use terminology and phrases that are familiar to the business domain of your application. By doing this you will make it so someone understanding your application will understand BATs written in that DSL.
I also always try to make a BAT DSL read as much as plain English as possible.
Once you have designed the DSL, you will need a way to implement it.
Microsoft also has a DSL SDK you can use in VS2010, although I haven’t used it myself.
The basic idea behind implementing a DSL is that you have to take some sort of grammar you design for your DSL, parse it into a syntax tree, then use that tree to generate code that will actually perform the actions.
It is by no means a trivial task, but using a tool like ANTLR, makes it much simpler than trying to completely generate a parser and execution engine yourself.
Why even bother?
Creating a DSL for your BATs is completely optional, but there are some significant benefits to doing so.
The biggest one I have found is that you are much more likely to get business people to write BATs if you have a simple DSL they can use to create them. Once you get everyone using BATs to define behavior and requirements, communication becomes much more simple.
Another great thing about creating a DSL is that you can create a runner that can interpret the DSL BAT scripts which can be run on any machine. Typically, to run BATs created in Java or C#, you would need a C# or Java compiler and a test runner, etc. By creating a DSL and a stand alone executor, you can very easily allow anyone to run BATs with little to no setup.
Writing your BATs in a DSL will also make writing the BATs and understanding them much easier. A good DSL can get rid of all the little language and API nuances that don’t really add information to the specific domain you are working in. A good DSL strips information down to the minimum amount needed and is able to do so, because it assumes the context is your application’s business domain.
You will also find that you are better able to separate framework from tests when you have a DSL in place. One issue that many teams face when creating a BAT framework is that some people come along and write lower level code in the higher level BATs. This creates a problem because it is hard to force someone to use the higher level API when the framework and the BAT code are the same language.
Wrapping it up
So that completes my series on Getting up to BAT.
Hopefully you have learned enough to be able to implement your own BAT framework and get BATs running for your application.
I tried to cover most of the important steps here without getting too deep into the details.
If you have any questions or are interested in getting more in depth training or consulting on getting BATs setup for your environment, send me an email or leave a comment.
It can be a little difficult to get started and get a BAT framework up and running, but the rewards are well worth the effort!