Ver 1.0 + This page/section is new to 1.0 and is not applicable to older versions

Introduction

In version 1.0 there is a big shift in the manifestation of WET UI's philosophy. Although nothing about the philosophy of WET UI itself has changed, version 0.9.8's WET UI was presenting a notion that test automation can be done by merely recording some sequences using WET's simulated browser and playing them back. This is far from the truth. All of us behind WET are of the firm belief that test automation is a discipline akin to development and also needs a strong experience in manual testing. Somewhere in our effort to bring down the learning curve for WET and to have UI utilities to ease the steps towards creating automation scripts, we screwed up and sent the wrong signals that WET (UI) is a record / playback tool that can be used to generate test automation suites that can later on be played back. Nothing can be further from the truth! The WET UI was only meant to be an assistant to the tester and not take the role of the tester itself.

Each WET Utility is a separate application now

We have redesigned the WET UI in such a way that the core philosophy itself is retained but the myth is done away with. We did this by simply disintegrating the various utilities that WET provides into separate applications. To illustrate take an example of automating a simple google search. Using WET 0.9.8, the tester had to

• Open the WET UI, a single MDI application
• Launch a browser and navigate to google
• Using WET UI, perform a sync with this google browser
• In the WET UI's simulated browser, perform various operations
• WET UI inturn was:
  • Creating a test definition file automatically
  • Creating an object depot automatically. This object depot had references to those elements in the page on which any operation was done at all.
  • Creating scripts based on the user actions automatically.

All this makes WET look like a record-playback tool and everything is done automatically. However it is not obvious as to how/why these components were interacting. As a result, most of the times, the real power of WET was not being harnessed to its fullest.

To address, this in 1.0, the various components of the WET UI are now separate applications by themselves - although it is possible to associate these applications with one another where applicable!

WET UI Components

The following are the main components of the WET UI:

1. WET Manager - This is the main control panel to allow launching of the different utilities of WET
2. IE Simulated Browser - Simulated browser that connects to an IE browser that is already open on the system. The tester can perform various actions on this simulated browser to help generate scripts
3. WET Treeview - Application that connects to an open IE Browser and displays the elements of the page using a Tree view. The tester can perform various actions on this simulated browser to help generate scripts
4. WET Simulated Browser - Similar to the IE Simulated browser. Only difference is that in this case, the page is constructed by WET itself and the look and feel is not the same as the actual browser. The tester can perform various actions on this simulated browser to help generate scripts.
5. Object depot manager - An application to manage object depots (aka object repository)
6. Test definition editor - Application to create and edit WET Test definitions. Compared to the 0.9.8 release, the new Test definition manager is 'dumber'. It is just an editor and nothing else!
7. Script editor - A simple text editor to edit test scripts

Reduced dependancy on the WET RPC mechanism

Besides the disintegration of the WET UI, the other big change in this version is that the dependancy on the RPC has been brought down. Previously both the sync with browser operations and perform operation on browser were dependant on the RPC mechanism. Sync with browser means get the contents of the actual IE browser and display it on the simulated browser / treeview. Perform operation is the step where the user actions on the simulated browser (/treeview) are performed on the actual IE Browser (ex. click a link). In WET 1.0, the sync with browser is done directly by the simulated browser itself without making RPC invocations. This eliminates some of the problems that users encountered due to the RPC communication. The perform operation however still uses RPC - and this is the right thing to do as the WET core layer is in ruby!

And finally apologies to ...

For those users who are using the integrated WET UI that shipped with 0.9.8 and like it for the centralized way of creating WET scripts, we are really sorry that we wont be able to maintain the integrated UI any more. While disintegrating the WET UI, we have also added many features to these 'seperated' applications which is simply not possible to add back to the older version. Therefore, we just can't continue to provide the integrated WET UI anymore. Once you start getting used to the new WET UI, we are confident that you will find the new way of using the WET UI to create WET Tests suites a lot better.