I just wanted to mention that with regards to RobotFramework (RF), whether one actually likes and uses the framework or not, their specification of test library APIs and the remote library API / server specification, while not perfect or flawless, is thought out really well. Really well in that the test libraries and remote library servers can be reused or re-purposed for other uses outside of RF, like for integration with other test frameworks. I can be wrong, but I don’t think there are many other test frameworks (though there are some) that offer the same type of reuse.
RF test libraries – in general (but does not apply to all libraries), are designed such that they are like class libraries, modular components, such that you can reuse them within frameworks that use the same language platform (Python, Java). You call the keyword methods as normal class library methods.
RF (generic) remote (library) servers – are even better. Their specification based on XML-RPC, while a bit outdated compared to say REST (on top of HTTP) or SOAP, is still very useful. Combined with RF test libraries served via the remote servers, you can easily integrate tools of other platforms/languages into your main test framework platform by exposing those other tools via a (XML-RPC based) web service, even when they natively aren’t web service enabled, as long as they are usable as RF test libraries (for the given remote server).
Cases in point:
- I successfully integrated (for a prototype demo) calling Sikuli image recognition tool and AutoIt remotely via PHPUnit-Selenium framework such that they can be used in Selenium Grid tests, provided you knew which nodes a running Selenium test to execute Sikuli/AutoIt against. But that isn’t so hard to do if you set up the Grid configuration such that you’d always knew which nodes the tests would run on for specific tests. The integration required creating special PHP functions that make use of a PHP XML-RPC client to talk to Sikuli and AutoIt RF test libraries remotely via the remote server. In the case of Sikuli, it’s a Java library served via the Java remote server. In the case of AutoIt, as I didn’t need the full AutoItLibrary from RF, just a subset, I wrote a simple custom AutoIt library in Perl and served it via the Perl remote server.
- The Sikuli Java library I wrote offers a command line interface to execute Sikuli API commands without writing a Sikuli script (to be run with Sikuli IDE). But it’s also a class library that simplifies the Sikuli API offering a simpler API on top of Sikuli for quick use and by novice users.
- I created a RF test library to manage Hyper-V virtual machines, and as it is a .NET class library, it can be used outside of RF to easily manage Hyper-V with a simple API.
See the GitHub gist PHP example below on how I integrated some RF libraries and remote server with PHPUnit for testing. Note that it only presents code from the PHP side, not the RF remote server & library side, which a RF user/developer should already be familiar with. See resources section at end of post for some of the libraries and servers used in the gist.
I encourage users and developers of RF (and it’s related libraries, projects) to explore usage of test libraries and remote servers outside of RF.
I also encourage those evaluating RF but end up not using it to explore possibilities of partially using it by reusing the test libraries and/or remote servers in another framework, etc.
You may find you might have some other uses for them.
Reference resources to some RF test libraries and remote servers (mentioned in blog post or not):