I am into the automation of a web application using Selenium. I write test cases without hard-coding anything in the test cases. There were many invalid failures in the run due to GUI changes such as page title change. I moved the page title verification to separate modules that are reused and called by many test cases so that I do not need to fix all the test cases but only few modules.

But I can see that there are around 10 modules that I need to fix in the last minute due to these changes. As a solution I declared and assigned these GUI element identifiers as global variables in a file inside config folder and reuse it in the modules.

My question is: is there any better approach / way to solve this problem? Is there any tool to effectively maintain and organize these global variables since there would be thousands?

Pseudo-code of my solution:
Global variable declaration in a separate file in config folder:

    public class globalVariable
        public final String HOME_PAGETITLE = "Welcome to Home page";

Modules calling it:

    public class module
        //Instantiate globalVariable class to use it's variables in module 
        globalVariable test = new globalVariable();

        public void testHome()
        //Call the global variable declared
        String strExpectedPageTitle=test.HOME_PAGETITLE;

        //Verify page title

4 Answers 4


Yes. The Page Object pattern is a good technique, and is the logical conclusion you are working towards already by extracting reused logic into methods. With this pattern, you create a model of every page in your UI. These page models are the only part of your program that know anything about your UI. Then, if the home page title changes, you just update the GetTitle method on the HomePage object. Your tests never access the title object directly, but only through methods on the HomePage object. This limits the amount of code you need to update for logic changes to just one class per change, and hopefully just a handful of methods. Note that you will want a separate Page object for your master page, if you have one.

Your Page objects can also use configured values stored in a text config file that is read at run time for strings, so you don't need to recompile your code just because an identifier changed. This is very useful when testing two versions of the same webpage at once, where identifiers might have changed between versions.

The same techniques work for other UI automation languages; I'm using these techniques in WatiN right now.


It sounds as if you try to avoid duplication in your automated tests. That is a good practice to follow, not only in automation but in programming in general.

For static strings, you might consider using property files instead of Java classes, especially if there are literally thousands of such values.

Ask yourself whether you are testing at the right level of detail. Are these thousands of strings you are checking (e.g. page titles) the result of some kind of requirement, or do they change at someone's whim? In my experience, it is the latter. If that is true, what do you hope to accomplish by checking these values? To put it another way, if your automated test fails on a string check, what will you do? If your answer is, "I will update my test to reflect how the UI has changed" then perhaps your test is not designed to find bugs. If that is true, you might ask yourself whether your test serves a useful purpose.

  • Thanks for your suggestions. I incorporate page title verifications in the test code to check whether the page is loaded correctly or not. It also ensures that the expected page is available and ready to test. In the last minute we did not have time to check why they changed the page title. It could be for business reasons. The end users don't like to see the same page title always, they want to see something different
    – Aruna
    Jul 7, 2011 at 2:16

Is the purpose of the test to verify 'page titles' or are you using page titles to validate state?

If purpose is to verify page title match, then I would say automation is probably not optimum solution even if there are many 'page titles' to validate.

If purpose is to verify state (e.g. to sync test), then you might consider doing a partial string match rather than trying to match a whole string. (e.g. in C# string.Compare()) But, you could still potentially run into unexpected false positives. Also, this approach also becomes a nightmare if you also need run these tests on localized builds.

If strings in the project are in resource files, then best bet may be to get the appropriate string from the resource file by resource ID and compare against appropriate string.


My general advice would be different, but in this circumstance I would probably move this content to a database table with three columns: PageName, PageURL and PageTitle. Then I would build some matching code that looks up the url of the current page, then checks the title. The code then becomes


Your code is still essentially hard-coding because you still have test.HOME_PAGETITLE in lots places in your code, which you want to minimise. Essentially get your code to work out what it needs to verify by itself.

  • Agreed, having test.HOME_PAGETITLE at many places is a drawback. Thanks for pointing it out. I am afraid retrieving the page title from database might make the test case slow and cause overhead due to DB connection. Please let me know your thoughts on this.
    – Aruna
    Jul 7, 2011 at 2:18
  • Database lookups are fast enough for that purpose, especially relative to loading a web page that also must perform one or more database queries.
    – user246
    Jul 7, 2011 at 13:19
  • If you use SQLite it is all in memory and quick Jul 7, 2011 at 21:09
  • Yep, but I found maintaining configurations in Spring XML or even in Java/C# classes is way easier than maintenance of test data in DB.
    – dzieciou
    Feb 28, 2016 at 21:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.