Robust Portlet Testing +

Robust and durable

Testing of web applications isn’t easy. If you are in a portlet environment things getting even more complicated. A portlet is a web application for itself and there could be a lot of different combinations on every page. There could also be many instances of each portlet on a page.

What are the consequences?
You couldn’t use normal ids on tags, because ids are unique on a page which conflicts when many instances of the portlet are on the same page.

A portal is themeable. The design and also the HTML structure depends on the user settings.

Portlets could be rearranged on a page, which means that the HTML structure is changing every time a new portlet is on a page or a portlet is moved to another place.

Lessons we learned with portlet testing

Nice but unstable

Try to write your tests as robust as possible. Nothing is as painful as seeing your test suite fallen to the ground.

You are developing a new theme or modifying your old one and all locators, in all tests, every field is broken.

You have a defined a set of portlets. Suddenly you need new portlets in this setup. You added the portlet at the top of the page and the tests are broken again.

Make portlet testing fun again.

Using XPath the right way

There are three tipps:

• Isolation
• Wildcards
• Abstraction

Isolation:

Normally there is a surrounding div-container with an id of the portlet instance. Try to use this element as entry point for your XPath. If you use the generated XPath expression of a tool like Selenium IDE, XPath Checker or other tools you will never get structured expressions which are easy maintainable.

//div[@id='agimatec_portlet_curatorArcaeEdit__CuratorArcaeEditPortlet_WAR_ostiumcuratorarcae__editParcel']

Wildcards:

I have never seen a portal source code with a really clean html structure. Because there are many columns, many layouts, many supported browsers you end in a kind of tag soup. Yes you can get an XPath expression with 20 elements. As mentioned there are tools which are generating the expression, but one change and you are doing the work again. Use a kind of wildcards in XPath. With the isolation you are at the portlet instance and right into your own code. Maybe there is just one table inside the portlet, but a lot of more div-layers between the table. With the // syntax you can navigate recursive to the next child element of that type.

//div[@id='agimatec_portlet_curatorArcaeEdit__CuratorArcaeEditPortlet_WAR_ostiumcuratorarcae__editParcel']//table/tr[1]/td[2]

Abstraction:

Don’t write the same code again and again. Write a helper which constructs the XPath for you. If you use a framework to build your forms, you can write a library which navigates directly to the form elements. XPath expression aren’t fun. It is better that it hurts one person than the hole team. Strive for abstraction.

detailPath().tab(1).ostiumTable().tr(1).td(2).toString())

Conclusion

There are a lot of tools for test recording. If you are using Selenium it is the Selenium IDE, if you use WebTest there is the WebTest Recorder. These tools are great for starting your web tests. But if your test suite is getting larger and you are working in an agile environment things are changing. Things are changing to often for maintaining recorded tests.

Learn with recorders but test with logic