Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
Tracking change and innovation in the enterprise software development community
Posted by Alexander Olaru on Feb 04, 2008 10:30 AM
According to the project's website, the primary target users for The Grinder are "people who understand the code that they're hitting - it's not just a 'black box' with a set of associated response times. Since tests can be coded - and not simply scripted, programmers get to test interior tiers of their application and not just response time via the user interface." The main new features of The Grinder 3 are:
In an interview with InfoQ, The Grinder project lead Philip Aston shared some background related to the technical decisions that drove the new release features and provided more background about The Grinder. Aston started by explaining the reason for adding scripting support:
The Grinder 2 was popular, but had an extremely limited script format for HTTP testing based on a properties file. I introduced dynamic scripting to allow branching, looping, and custom validation in HTTP test scripts. The script language also has the huge advantage of allowing other types of testing directly from the script, without requiring a custom plug-in.
Aston also gave some insight and interesting history in regards to why Python was chosen as the scripting language vs. using Java for writing test scripts or other scripting languages with JVM support:
I ruled out Java as a scripting language because a goal of The Grinder 3 is to be as easy to use for HTTP testing as The Grinder 2. Separate compilation cycles, fiddling with class paths, and so on, would get in the way of this. That being said, Jython has first class integration with Java, and Java code can easily be tested (see the many examples in the script gallery).
I began working on The Grinder 3 in 2001 when Jython and Groovy were the only horses in the JVM scripting town, so I didn't need to think too hard. Jython has proven to be a good choice for The Grinder. Python is easier than most languages for people to pick up for occasional use. Many users of The Grinder are not Java experts, and simply want to make minor modifications to recorded scripts. On the other hand, Python is a powerful tool for developers who want to use The Grinder for more advanced scenarios; and Jython allows existing Java libraries to be mixed in at will.
The discussion continued with Aston sharing details about TCPProxy - a proxy process that can be placed in a TCP stream, such as the HTTP connection between a browser and a server. Aston mentioned that TCPProxy can record test scripts in Python and identify dynamic variables in URL parameters and forms. He added that "users typically start with a recorded script, then modify it to include/change the user account and other application data that is used, or merge the script with others to generate load covering a mixture of scenarios". Once set up, the test scripts can be controlled and monitored through The Grinder Console.
Version 3 dropped support for a number of settings in the grinder.properties file associated with the prior release as these configurations can now be set directly in the test scripts. He explained what would be the recommended transition path for test scripts written for The Grinder 2:
The Grinder 3 ships with an example script that can interpret a Grinder 2 properties file, but I would recommend re-recording the test script. Scripts can be recorded with the TCPProxy and then replayed in much the same way they could with The Grinder 2. With The Grinder 2, the only way to alter or extend the behavior of the script was to write a plug-in, or in extreme cases, modify The Grinder itself. With The Grinder 3, pretty much anything is possible within the test script itself.
The interview concluded with Aston mentioning that the recent appearance of 3 related projects -- Grinderstone, webFlange and Grinder Analyzer -- finally convinced him to remove the beta label from The Grinder.
5 Ways to Ensure Application Performance
Performance Management and Diagnostics in Distributed Java and .NET Applications
Business Benefits of Open Source SOA
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.
This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.
This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.
This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.
After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.
IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.
Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.
No comments
Watch Thread Reply