SOLID Principles for Testers: The Single Responsibility Principle

Those who have been reading my blog for several years have probably figured out that when I want to learn something, I challenge myself to write a blog post about it. In 2020, I read one book on software testing each month and wrote a book review. In 2023, I learned about one Logical Fallacy each month, and wrote a post explaining it (which eventually turned into my book, Logical Fallacies for Testers).

For the next five months, I’ll be taking on a new challenge: learning about the SOLID principles of clean code. I’ve wanted to understand these for years, but I’ve always felt intimidated by the terminology (“Liskov Substitution” just sounds so complicated!). But I’m going to do my best to learn these principles, and explain them with examples that will be useful to software testers. So let’s begin with the Single Responsibility Principle, the “S” in SOLID.

The Single Responsibility Principle says that a class should have only one responsibility. Let’s take a look at this Login class:

class Login {
     constructor() {}
     login(username, password) {
          driver.findElement(By.id('username'))
               .sendKeys(username)
          driver.findElement(By.id('password'))
               .sendKeys(password)
          driver.findElement(By.id('submit')).click()
     }

     navigate(url) {
          driver.get(url)
     }
}

The Login class has two methods: login and navigate. For anyone writing test automation this appears to make sense, because login and navigation often happen at the beginning of a test. But logging in and navigating are actually two very different things.

Let’s imagine that multi-factor authentication is now an option for users of the application. The test automation engineer will now want to add a new login method that includes multi-factor auth. But what will the impact be on the navigation method? It could be that there is no impact at all, but if new package imports need to be added to the class, it’s possible that they could break the navigation method.

Any time a class changes, there’s a chance of breaking existing functionality. The test automation engineer will need to check every test that has navigation in addition to checking every test that has logging in.

This is why it’s best to give classes just one single responsibility. The navigation method should be moved to its own class. Then when new login methods are added, the navigation method will be completely unaffected. And it will also be possible to add new navigation methods to the navigation class without affecting the login methods!