Mix and match over inheritance for test automation

Today, I like to talk about test automation design.

First, I like to ask you, test engineers. How much effort does project team put on test automation design? Project team meaning Dev,Test,PM and even architect. Here is a similar question. How much effort does project team put on dev design and code review vs test automation design and test code review? Does your company architect spend time on test automation design?

Is it too obvious question? I think the project team should focus more on dev design and implementation because that is what eventually the company deliver to the customers.

What I'm trying to say here is that since the focus is on dev side, testing side design and implementation tend to be sole responsibility of test engineers. Therefore, you and I, test engineers, should be able to come up with robust and reliable test automation. Which means design of test automation should be well thought through.

Let me cut the intro part here and get to the point. The test automation design.

1. Test Runner. What is the responsibility of test runner? Java world JUnit or TestNG in .Net world NUnit. I believe test runner should be responsible for running tests and only running. Test runner by itself should not have functionality other than executing your test code. I've seen many cases where the test runner extends several crafted base classes. I'm not trying to reference the book like "Gang of 4 design pattern" says that favour composition over inheritance. (It's a great book by the way. And you probably read that several times already). Just simply look at how much flexibility we are loosing by inheriting other base class. Before inheriting the base class, test runner was like "I can run anything!" After inheriting base class, it is like "I'm specialized in running xxx tests". As the project grow, your test runner becomes more and more specialized in running xxx tests.

2. Power of mix and match. I think we can take out commonly used functionality in base classes and put them in feature specific common folder. As the project grow, you will have more classes to put in common folder. But test runner will still like "I can run anything!" We, test engineers, can use any class that makes sense for running test cases. If we find more generic class in feature specific common folder, we can move them up to project level common folder.

3. never say "never/always". When you prepare test automation, try not to convince yourself by saying when I run tests "yyy" will always have to run. You can put "yyy" in setup method in test runner. And "yyy" can be changed and "yyy" may not be used 6 months from now.