verifyTextPresent, typeKeys and key* – The Deprecation

Note: I wrote this post before Selenium IDE 2.4.0 was released and was not able to publish it until now. I have not made any changes.

In the next version of Selenium IDE, the verifyTextPresent command and some others will be deprecated. Unless you have strong reasons for staying with these, I would recommend that you move away from them. The alternative suggestions are now built into Selenium IDE itself. When it detects that you are using a command that is marked as deprecated, the reference section will inform you that the command is deprecated along with alternative commands.

What does it mean for you?

While I have marked these as deprecated, I am not going to remove these commands. They will continue to be available, so you can continue to use them in your existing tests. If you are trying to create new tests, it is a good idea to avoid these deprecated commands and try to use the alternative ones.

These deprecated commands are supported by Selenium Core and since it has reached end of life, supporting all commands is going to be increasingly difficult. Deprecating commands is one way to reduce the scope of commands that we need to maintain. Another reason for the deprecation is that we are trying to move to a more user centric approach for Selenium. This is quite evident with the new Webdriver API. The new mantra is – do what a real user can do.

There are going to be more commands that will be deprecated over time. Every time a command is deprecated, there will be alternate commands that can be used. And tools to help you migrate over to the new commands as painlessly as possible. I do not use Selenium IDE extensively, so I do not know what and how you use Selenium IDE. I can only guess, so your feedback is always useful. If you can present your use cases, it will be incredibly useful.

The verifyTextPresent Command

The reason I deprecated this command is that it gets the text of the whole webpage and looks for a pattern in it. It is an incredibly expensive operation and its use is very widespread and in my opinion always unnecessary. Unless the application you are trying to test is completely random or very badly created, you should have some element you can narrow your search to. The best thing to do is to narrow down to the exact element that should contain the pattern you are looking for. Substitute verifyTextPresent with verifyText with the locator of this element. And if you can find nothing, as the last resort, use BODY as the locator, effectively emulating the same behaviour as verifyTextPresent.

The typeKeys and other key* Commands

The typeKeys command was to try and simulate the user pressing keys. This is because some web applications do stuff based on the events that are generated as you type. The usual command type simply changes the content in a field without firing all these events. The sendKeys command emulates the exact user behaviour of user typing keys and is a replacement for all the typeKeys command and the keyUp, keyPress and keyDown commands. It is not a replacement for the type command. I would recommend that you use the type command first and if things don’t go as expected, try the sendKeys command. As you have seen in my previous posts, the sendKeys command can press special keys as well. One thing that you will notice that sendKeys does will not remove existing text. If you always want the field to be empty, use a type command to clear the field or use special keys in sendKeys to select all the content in the field first.

 Potential Problems and Solutions

Many users of Selenium IDE run the test suites using the htmlsuite option of Selenium RC (now bundled in the Selenium Server). The new commands I introduced in Selenium IDE have not been ported to Selenium RC. The API for Selenium RC is frozen and introducing new commands is generally frowned upon. I have been exploring solutions that will hopefully keep users of Selenium IDE happy. One feature that I have been working on is to allow users to schedule tests at specific times within Selenium IDE itself. Test suites can be run automatically at particular times without any external tools or user permissions. I expect the first cut to be available after the next couple of releases.