30 Days of Automation in Testing | Tests & Testability

Dear Reader,

Regarding the subject of testability, there are many opinions that yield similar single conclusion: code, as it is written, ought to be testable.

Where the divergence happens is in how the aforementioned code is written. Some take to abstractions, where chunks of code are split off into separate sections.

Others keep the code in-line leading to verbose composition.

Then along comes the Single Responsibility Principle.

What the Single Responsibility Principle (SRP) taught me, a noOb Automation Engineer

Not too long ago, an awesome teammate (Dev) introduced me to SRP and the code concepts behind it.

We were working on a project and our synergy was off-the-charts. I would automate a lot of the test efforts thereby maximizing the turn-around time to fixing bugs and he would help with code reviews and solutions when I hit a wall.

Along the way, he passed along the tidbit of information regarding SRP and it opened my mind to a new way of thinking about how I need to restructure my tests.

Code Quality

One of the first take-aways from learning about SRP and S.O.L.I.D. principles (click link for more details) is that test and the code they're written ought to be neatly composed and clearly structured.

• A class should only have one reason for change.
• A class can have many functions, but not the other way around.
• A module should never consist of multiple classes.

Code Efficiency

Another take-way was modularization of tests.

• Increased Speed - By keeping modules separate, the speed with which tests fire become greatly improved.
• Greater Reliability - modularizing tests increased reliability at deployment and improved as more and more tests were added to the test bed.
• Flexibility - as the project evolved, tests can be updated / removed with minimal to no impact to the rest of the test suite

Code Legibility

• Improving code efficiency parlayed into better code legibility. By abstracting tests into methods and keeping classes separate, I went from a verbose test filled with "spaghetti code", method calls, variables, and the like, to something that reads like:
• openBrowser(url)
• onTheHomePage.clickLogin()
• onTheLoginPage.enterCredentials()
• onTheLoginPage.assertLoginIsSuccessful(message)
• closeBrowser()

Code Maintenance

As more and more tests were added, and the test suite ballooned to well over 40 tests, the need to maintain this volume of tests, and test resources that went along with it, began increase proportionately. With the application SRP, test maintenance became less daunting.

• Test Data - Data that feed the variables for a test step now came from an external data source instead of being hard-coded.
• Test Scripts - with the ease of legibility, tests could now be shared and discussed with non-technical members of the team. Feedback yielded additional action in record time.
• Test Reporting - with the improved structure, tests could now better reflect what was being tested making reports and error handling much more succinct.

Conclusion (tl;dr)

Single-Responsibility Principle & S.O.L.I.D proved instrumental in how best to structure my tests scripts into a clean, concise, legible test harness that proved to be efficient and effective at articulating workflows, providing timely feedback to the Developers, and finding bugs in a reliable manner.

Resources:

• SRP Wiki - https://en.wikipedia.org/wiki/Single_responsibility_principle
• https://code.tutsplus.com/tutorials/solid-part-1-the-single-responsibility-principle--net-36074
• https://codeburst.io/understanding-solid-principles-single-responsibility-b7c7ec0bf80