DSL and Testing: using JSR in the Polyglot Architecture.
Long ago, we started working with a Client, PushToTest, that has a tool for testing. The main idea of this tool was the ability to repurpose unit tests into functional, load and Monitor tests. It has also a proxy to record all transactions against a web page, so the transactions could be replayed later. At some stage, the intermediate language chosen to script tests and record the transactions was Jython.
Over the years, it was learned that not all people knew Jython, nor Python nor Java. So, other scripts were added, adding support for popular solutions like Selenium and SOAPUI. Still, we found there were cases where developers had code snippets written in their language of heart, by that ruby, scheme, and others. Then the goal of the tool became being as flexible as we could make it, So, JSR 223 was added to the mix using the external implementation in Java 5, and later using the integrated one of Java 6.
The next step in evolution was to create a communication environment, in a way such that complex transactions testing was possible using at each step the appropriate technology. For instance, we may use … to process data files and execute updates to web services using SOAPUI. Later, we will verify the data is updated in the database by issuing a web report request using selenium. To do this, all scripts should share info, communicate. We created DPLs (data production libraries) able to provide sample data to the running tests, across threads (we simulated multiple user using threads). Some scripts were able to execute methods from objects created in other languages, and we were able to create complex scenarios by launching different groups of threads with multiple roles (for instance, some consumers and other providers, or some posting blogs, some others searching, others registering and other running reports).
To create such a complex system, architecture was the key. One part, what we call the polyglot architecture, is a simple abstraction of runners that allow a central controller to run different tools and languages.
Furthermore. For some of our clients, we were in the need to create simplified languages or scripts. We could do some of those things on java or jython, but we would be forcing the client to learn java to actually modify the scripts. In those cases, we created simplistic languages with a handful of operations, that may be run with a particular runner. Yes, those were little DSLs, and the magic of JSR 223 allow us to integrate them seamlessly into the polyglot architecture.
Want to learn more about this? I will try to explain what a practical DSL is, how to use them for testing, and how to implement a JSR 223 engine for them. From that to the polyglot architecture, it is just a copy step.
What is a REST API, anyway.
Have you ever wondered what an API is? Well, API may be a common used word, but many just give the definition for granted and had had no second thought about it. Now, REST is an architecture style for networked systems. Given that, how would a RESTFul API look like? This is the question we will discuss in the chat. Actually we will see that many of the APIs have not much in common with REST, and that you may be creating a simple web api rather than a full REST one.
