WET Web Tester[1] is a web testing tool that drives an IE browser directly, so the automated testing done is equivalent to how a user would drive the web pages. The tool allows a user to perform all the operations required for testing web applications – like automatically clicking a link, entering text in a text field, clicking a button, etc. One may also perform various checks as a part of the testing process by using Checkpoints. The latest version of WET is 1.0.0.
WET sits on top of Watir,[2] an automated test tool which uses the Ruby scripting language. WET retains all the features that Watir has and adds many usability related functionalities, such as data table support, object depot (aka object repository) and inbuilt HTML reporting.
History
editWET started off as an Extension Toolkit to Watir, a framework for Web testing, released as an opensource product and called it as WET (Watir Extension Toolkit).
Technical details
editWorking Principle
editA UI Test automation is conventionally done by either using a record and playback technique or by scripting completely.
- In the record-playback technique, the tool automatically captures the events generated by the tester's actions and converts them to test scripts. These scripts can then be played back subsequently. While the record and playback technique allows testers to quickly create tests, experienced testers tend to detest using this approach due to the reliability and maintainability problem posed by these.[3]
- The scripting technique relies on an experienced tester writing test scripts from scratch. Experienced test automation engineers follow a complete software engineer process and treat the test automation effort as another development effort. While this technique offers the advantages of a well maintainable and reliable code, it suffers from certain drawbacks like requiring a greater experience pool, a larger budget, etc.[4]
The third technique is a middle solution that offers some of the conveniences of recorders while retaining the complete scripting power. WET has adopted this technique, called as the Proxied UI technique for test automation. Using this methodology, a tester instructs an IE browser (using some sort of a wizard) to perform various steps like clicking a link, setting text in a textfield, selecting a list box, etc. The tool then converts these instructions to test scripts. Unlike the recorders, where scripts are generated by the tool automatically based on the actions that the user performed on the actual browser, in this case scripts are created only when the tester asks the tool to do so. This by itself increases the accuracy of the generated scripts. Using these scripts as the baseline, a tester can increase the test coverage by writing scripts to suit his application under test.[5]
Be it a total scripting, record and playback or the Proxied UI solution, each comes with its own benefits and liabilities.[6] One advantage of the Proxied UI technique is that it gives control to the tester to decide how much of script generation is to be used vs. how much of hand written scripts. This is a decision that needs to be taken based on the application under test and the test coverage required. In a good project, there should be a proper mix between these techniques so that the benefits of each technique can be availed.[6][7]
Features
editThe following are the important features of WET:
- WET UI – Preliminary Script development can be done using the WET UI which is easy to use. Using the WET UI, a tester can create Test Definitions, Object Repositories and the first draft of the test scripts.
- Scripting using Ruby – WET uses Ruby, an object oriented scripting language, which in turn gives WET a powerful scripting ability
- Object depot – The Object depot (aka Object Repository) allows a tester to map all the application's objects into centralized repositories. This helps in a higher maintainability of scripts.
- Object identification using multiple parameters – Many web pages are designed in such a way that the same page has elements with similar attributes – For example, there may be text fields with the label 'name' – one may be for the User's name while the other may be for the Developer's name. WET allows a tester to identify even these kind of objects by letting to search for objects using multiple parameters.
- 'Test definitions' to define tests – The structure and flow of a WET test is controlled by a test definitions file. This flow closely mimics the regular manual testing process.
- Slick HTML results – After the tests are completed, the results are printed out in neat HTML Format
- Integrated Data table support – Testers can write data-driven tests by using the Integrated data table support. Data tables can either be as Excel files or XML format.
- Popup handling – WET handles Win32 popups quite reliably.
Limitations
editThe following are some shortcomings in WET:
- Supports only the IE browser. Cannot be used for compatibility testing.
- The Simulated browser view of WET doesn't work accurately for a complex pages. For these sort of pages, one has to view objects in a tree view only.
- No integration with SCM / bug tracking tools
- Does not have support for keyword driven tests
See also
editReferences
edit- ^ WET. "Commercial Grade Web Automation Testing offering an Opensource alternative to Quicktest and Silktest". Wet.qantom.org. Retrieved 2010-10-12.
- ^ "Watir - Overview". Wtr.rubyforge.org. Archived from the original on 2005-02-06. Retrieved 2010-10-12.
- ^ bret (2005-08-17). "Testing Hotlist Update: August 2005 Archives". Io.com. Retrieved 2010-10-12.
- ^ "Guidelines for Scripting languages in Test Automation" (PDF). Retrieved 2010-10-12.
- ^ WET. "Test Automation with the ease of recording". Wet.qantom.org. Retrieved 2010-10-12.
- ^ a b "Test Automation Snake Oil" (PDF). Retrieved 2023-10-28.
- ^ "Software Test Automation - Myths and Facts" (PDF). Archived from the original (PDF) on 2007-09-27. Retrieved 2007-08-07.