Question

Here’s the situation that I’m working with:

• Build tests in Selenium
• Get all the tests running correctly (in Firefox)
• Export all the tests to MSTest (so that each test can be run in IE, Chrome and FF)
• If any test needs to be modified, do that editing in Selenium IDE

So it’s a very one-way workflow. However, I’d now like to do a bit more automation. For instance, I’d like every test to run under each of two accounts. I’m getting into a maintenance issue. If I have 6 tests that I want to run under two accounts, suddenly I’d need 12 tests in the Selenium IDE tests. That’s too much editing. But a ton of that code is exactly the same.

How can I share chunks of Selenium tests among tests? Should I use Selenium IDE to develop the test first time then never use it again (only doing edits in VS after that)?

Answer 1

Selenium code is very linear after you export it from the IDE.

For example (ignore syntax):

  someTestMethod() {
     selenium.open("http://someLoginPage.com");
     selenium.type("usernameField", "foo");
     selenium.type("passwordField", "bar");
     selenium.click("loginButton");
     selenium.waitForPageToLoad("30000");
     assertTrue(selenium.isTextPresent("Welcome * foo"));
  }

This is the login page. Every single one of your tests will have to use it. You should refactor it into a method.

  someTestMethod(){
     selenium.open("http://someLoginPage.com");
     String username = "foo";
     String password = "bar";
     performLogin(username, password);
  }

  performLogin(String username, String password){
      selenium.type("usernameField", username);
      selenium.type("passwordField", password);
      selenium.click("loginButton");
      selenium.waitForPageToLoad("30000");
      assertTrue(selenium.isTextPresent("Welcome * foo"));
  }

The performLogin() method does not have to be in the same file as your test code itself. You can create a separate class for it with your methods and share it between your tests.

We have classes that correspond to certain functionalities on our UI. For example, we have many ways to search in our app. All methods that helps you with search functionality will be in the SearchUtil class.

Structuring your tests similarly will give you the following advantages:

• If the UI changes (an id of a field), you go to your one method, update the id and you are good to go
• If the flow of your logic changes you also have only one place to update
• To test whether your changes worked, you only have to run one of the tests to verify. All other tests use the same code so it should work.
• A lot more expressive as you look at the code. With well named methods, you create a higher level of abstraction that is easier to read and understand.
• Flexible and extensible! The possibilities are limitless. At this point you can use conditions, loops, exceptions, you can do your own reporting, etc…

This website is an excellent resource on what you are trying to accomplish.

Good Luck!