How did the automatic UI testing of Events start?
I have been trying to automate testing of the (UI) of the Events module for some time. The Events modules is extensive and has a lot of functionality. And although we have streamlined most of the code in the past 2 years, and feel confident about the quality of the module, our Events team is also very active and committed to improve and extend the Events module.
About a year back, I invested a number of Firefox add-ons to help with the UI testing, did a lot of testing with DejaClick, but found it to be difficult to create a set of tests that works efficiently in a DNN site. The fact that control ID’s are created at runtime and will be different after several installs and uninstalls of a module, is a big problem with UI screen recording and replay.
In May I followed a session of Kelly Ford (the creator of XMod) about his use of Selenium, an (open source) automatic testing tool with various options, including screen recording and replay, all for Firefox. And I became again enthusiastic about automatic UI testing.
What did we do to test Events automatically?
In the weeks after the session of Kelly, I started to do screen recording and test playback for Events 5.1.x (the Events release that is available as Release Candidate). And my experiments were very promising. Selenium proved to be very useful for test recording and editing, and flexible enough (with some clever control resolving) to cope with the dynamic structure of a DNN site.
When I submitted the Events release to the DNN release tracker, I contacted Declan Ward, who was appointed to do the testing of the release of Events. Declan followed a session of Kelly Ford during the Day of DotNetNuke Europe in Paris and was enthusiastic as well.
I could describe what we have done, but Declan has created an excellent blog on his personal site about his experiences with Selenium and automatic testing of the Events module. He provides several screenshots and even a video illustrating some of the automatic testing.
Have a look at the blog of Declan here. Feel free to comment his blog or enter some comments here.
The automatic UI testing proved to be very worthwhile. Today I create a new release candidate of Events and Declan was able to run all the Events tests automatically (10-15 minutes). It did involve some work to get up and running and create the tests in the first place, but once they are available, testing goes much, much quicker.
For upcoming release of Events, we will make the test recording scripts available through CodePlex. As a learning experience available for anybody who is interested.
Does Selenium tests everything?
No, off course not. Unit testing (which we currently have not done for Events) can provide detailed tests of the inner workings of the code in the module and provides a different way of achieving the goal: a well tested and reliable module.
Selenium is (in the way we applied it) a very clever screen recording and replay tool, with various options for validation of the end result on a UI level. Selenium is a tool that can be used by non-developers on the final result without having access to the source code. As such, it proved to be very useful for the Events module and we expect to profit from our investment in future Event releases.