Introduction with Selenium IDE
A while ago I started my journey into testing applications. Like most people I started with Selenium IDE since it’s free, easy to install and setup. The idea was to record the workflow in an application and play it back after the development of every new feauture.
A nice idea but it does not work so well with the dynamic ID’s XPages generates for it’s controls. Instead of the id attribute you can then go via XPath and apply parameters. Here is an example for my Edit Box control that has id ‘inputCustusomerName’ -> starts with @id,’view:’ and contains @id,’inputCustusomerName’.
It becomes a lot of fiddling with the IDE and basically it becomes a long, long script (if you have a larger workflow) which you are capable of structuring in smaller pieces via the suite option.
When talking with more experienced test people they all drop the IDE and go for Selenium Webdriver. I will not go into details on WebDriver but the specs of WebDriver overclasses the IDE by far and it’s available in different languages. Since my XPages applications are already written mostly in Java so one is acquainted in a sense with an Eclipse environment (DDE) the step to start writing code in Eclipse IDE is not that big.
So with WebDriver used across the organization I feel more assured to join that community instead working on tests on an island (with Domino is also in a way). We have actually an infrastructure for WebDriver with Selenium Grid and support via a framework based upon Selenium WebDriver.
When you start writing your tests in the beginning you end up like with the Selenium IDE in a long script that can do one thing. If you want to take the next leap then check TestNG. It extends the test capabilities by far and allows to structure and configure your tests to way you want.
ith TestNG your can setup ‘testsuites’ and in those suites you can define which tests to run. I use the suites to run tests in different roles.
At first I looked at the option to run my tests from DDE ( I found some posts/presentations where it looked it should be possible) to avoid moving to another development IDE. But after installing the TestNG plugin in DDE and writing some scripts using WebDriver when running the TestNG suite it searched for files that where outside my NSF (workspace directory location). So the option to remain coding in DDE I gave up.
If you work in a larger organization you are probably not the first person who writes tests. I found in my organization a supported test framework that is based upon Selenium WebDriver and TestNG and includes more features like for example ReportNG which allows you to create HTML reports of your tests. Selenium WebDriver has a feature to take a screenshot so that is nice to include in your test report.
The framework has many more features which I have not touched (yet).
With Selenium WebDriver you will face the same problems with dynamic id’s as in Selenium IDE. Use XPath as selector the web element e.g.:
When accessing lists, like link controls in a repeat control these XPath reference does not work. they all end with the same ID part. So when you register a new customer and that customer will appear in a table you do not know in which row that customer will appear depending on the content in that table. You can even have so many customers in the table so that you need to use a pager.
In Domino it is common you define userroles in your Access Control List and then distribute these roles to users/groups. Especially if you want to test a workflow you access the application in different roles. Via TestNG tend to provide a role as parameter, and for that role I use different user credentials. When working in a team and Git you do not want to expose these credentials so I started to use Jasypt for decrypting these values.
If you have an application that supports multiple languages you also want to check your application in those languages. In WebDriver you can find links by their text and these textes probably differ in languages.
Tests are a common part of development and in modern development test drive development. As a Domino developer you have to adapt to this paradigm. If your team is too small for test developers you probably have to write those test yourself. Writing tests expands your development skills and you talk with colleagues in different areas of your organization you otherwise never would have contact with.
Test is a wide area and I have only explored a part of it. Test is also an important part of CICD (continious integration continious delivery) if you happen to have as goal to deliver an automated process for the build of your Domino applications.
Good luck and enjoy the journey!