How to set up a selenium structure for multiple languages and browsers

[Virgil]

I am working on setting up a selenium structure which is supposed to run some portal UI and functional testing.

Regarding to the UI part, since the portal supports multiple languages and browsers, so is there a way to set up a durable and easily maintaining structure?

For example, if I am passing the language and browser as parameters to the test suite, then the parameter combination would be

Numbers_of_language * Numbers_of_Browsers

But if one language is NOT supported or is added, and we need to apply all test suites, then it's gonna be a huge work to do and very easily to make some mistake.

Is there a practical approach for this structure? I believe I am not the first ppl who is working on this, so please give me some advice.

Thanks

[Yevhen Bilevych]

Hi Virgil,

Not sure I understood the problem.

Are you saying that you have to modify all the test cases every time you
add new language support? Then it is, most probably, improper design.

Could you please show one of testcases to get more insights?

Thanks,
Yevhen

> --
> You received this message because you are subscribed to the Google
> Groups "testng-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to testng-users...@googlegroups.com.
> To post to this group, send email to testng...@googlegroups.com.
> Visit this group at http://groups.google.com/group/testng-users.
> For more options, visit https://groups.google.com/groups/opt_out.

[Rick Simpson]

Hi Virgil,

Our group faced the same problem and came up with an approach that gives us a lot of flexibility at run time, but is a bit complicated to put together.  We use Selenium so I'll speak in those terms, but even if you're not, this idea should work with other frameworks.  

Because we didn't want to be in the business of managing xml files, we chose to configure each run dynamically at run time using either command line parameters, or through a single config file.  Here's the basics...

We have a testConfig file--a simple properties file--where people can set values for how they want to execute the test run: browser, platform, browser version, languages, etc. These values act as a fallback if someone doesn't set something specifically.  We then have a configuration class that checks for system properties (cmd parameters) and sets its values if it finds any we're concerned about, and if not, it reads values from the testConfig.  We end up with a single object with all the configuration details for a particular run.

Next we have a "base"  test class that instantiates the config object, and from the config object parameters it does two things.  First it parses the config values and builds an array of all the combinations between browser/platform/browser version/language which is used to create a data provider.  Second it creates Selenium drivers for the combinations.  The final piece is that all our test classes extend the "base" test class and use a Factory to create an instances of the test class for every combination in the data provider.  

Essentially this lets us parameterize test runs on the fly. We use this approach to manage a lot of things: environment to test against, what flags to use to get to features under development, languages to run the tests, browsers and versions to use, how many times to retry failures, whether to run in a local browser or use a grid, what groups to use, setting the implicit time out, and a handful of other things specific to our landscape.  We use Jenkins a lot so this makes configuring jobs a piece of cake. 

The key points are: Have simple way to dynamically set the key configuration points; Have a base class that handles as much of the test class set up as it possibly can and have it build a data provider with all your combinations; Test classes that extend the base class and are parameterized by the data provider.

Hope that helps, or at least gives you something to consider.

R