We chose the use of the DoXXXX methods and Pascal case primarily because a lot of testers that use Rapise are using Rapise Visual Language (RVL) and we found that the naming conventions were familiar to them (since they usually are coming from the world of Excel macros and VBA).
- GetText - gets the text
- SetText - sets the text
- DoClick - clicks on something
We have considered adding camel case versions without the prefixes (e.g. click instead of DoClick) to the Rapise objects, but in our usability testing, we found that actually caused more confusion, because methods like "click" are native browser methods that are not the same as our DoClick() so it ended up being more confusing.
- object.click() - browser click event
- SeS("object").DoClick() - Rapise click action
So based on our testing and user feedback, we believe the current system makes sense for our users, both in JS and RVL modes.
For those looking for a bit more information:
- Rapise itself is a successor of another test automation product that had this naming convention. The “Do” naming for operations is inherited from that tool. When this earlier tool was created, this was a design requirement because the majority of test automation engineers were using VisualBasic and its variations, which had a similar naming. Even some JS libraries (such as SandCastle) were using Pascal Case because it is more common to .NET world where it is a standard de-facto.
- Since Rapise is a desktop application, it has support for COM/ActiveX and the majority of COM APIs are Pascal Case (i.e. MS Word, MS Excel).
- The idea of using JS instead of VB was revolutionary when Rapise was designed.
- The core Rapise engine uses some 3rd party JS libraries (such as md4 hash sum compiler and google XPath emulator for IE). But also it uses a lot of Win32 API calls, .NET calls, ActiveX libraries, so the libraries inside use a mixture of Pascal and camel Case.
- Currently, Rapise uses lowercase naming for internal APIs (i.e. each SeS object has .highlight() method). While all ‘public’ APIs are uppercase. So we use it as an explicit separator between user-level API and internal API.