Explaining how the real world works!     RSS Feed The Automated Tester on Twitter The Automated Tester on LinkedIn The AutomatedTester on github

Writing maintainable tests

Tue 22 Jun 2010

A question I get asked regularly, and is regularly asked on forums I visit, is how do "I make my tests maintainable?". This is normally from a tester upset that the developers are commenting out tests because they feel its too much work to update the tests. The next popular question is "how can I get my non-technical colleagues creating automated tests?". For me the answer to both is very similar. Make the tests self-documenting and easy to read (maybe using a DSL). You, as a developer, would do this with your production code so why not do it with your tests.

Now, what do I mean by self-documenting and easy to read?

  • Methods should explain what they are for. This goes for test and production.
    I like to format my test methods like ShouldDoX. This is similar to what BDD practioners do for their tests. If another prerson comes along to look at some code that you have written, and your tests, they will be able to see what you meant it to be doing.
    	 public void ShouldLoginAndChangeStatus() 
    	 
    for a social networking app explains exactly what they are expecting.
  • Methods and tests should be succinct
    Methods that are huge, in test and production, are likely to have bugs in them because people have to scroll to get to the bottom. They are likely to have business logic bugs when that happens. I also like abstract as much as I can so that it makes the code readable.

    Which is better for readability?
    	selenium.click("//a[contains(@blah,'someIdButNotAllOfIt)]")
    	

    or
    	// linkToCoolStuff is a constant holding the XPath above
    	selenium.click(linkToCoolStuff)
    	
  • Maybe using a DSL?
    We could take this one step further and create a DSL so that we do not have to care how it does it, we just know it will happen. For UI testing I like the idea of the Page Object design pattern for creating tests. You split the UI and the tests apart so that you can have a test looks like the following.
        [Test]
        public void ShouldLoadHomeThenGoToXpathTutorial()
        {
            Home home = new Home(selenium);
            SeleniumTutorials seleniumTutorials = home.ClickSelenium();
            SeleniumXPathTutorial seleniumXPathTutorial = seleniumTutorials.ClickXpathTutorial();
            Assert.True(seleniumXPathTutorial.
    					IsInputOnScreen(SeleniumXPathTutorial.FirstInput));
            Assert.True(seleniumXPathTutorial
    					.IsInputOnScreen(SeleniumXPathTutorial.SecondInput));
            Assert.True(seleniumXPathTutorial
    					.IsInputOnScreen(SeleniumXPathTutorial.Total));
        }
        

I have created a tutorial on how to use the Page Object Pattern with Selenium to make tests that are extremely maintainable and also allows non-technical people to write tests without having to understand how Selenium works.

    Area: blog

blog comments powered by Disqus