Common Design of Automation Test
migrate this article from https://www.linkedin.com/pulse/common-design-automation-test-rio-liu/
If you want to develop automation test project, I think you need to understand these common design/concepts.
test context has two parts: Test Environment Parameters and Test Case Input Parameters
Test Environment Parameters contains the basic environment info of test target, like QA env, Dev env, Production env. These context info will not be changed during the test and they're shared with all the test suites.
Test Case Input Parameters means the input properties of every test case, it is very flexible you can get it from different ways. like System Properties, YAML File etc.
Test Case I don't want to say too much here, because it depends on test requirements. I just want to mark it as key concept of automation.
We always need framework level coding to make our test code reusable and stable, it can be used in every test project to provide common functionalities. it can improve test development speed and test developer can spend more time on test cases.
Logging is very important in automation project, we need it to track test progress and catch the failures. Normally we need 2 levels of logging, one is console log, we can output some detailed debug log in system console, another is the logging on report page. We need to publish Web base report page to share with other teams and management. So Logging utilities need to provide two levels for logging. for example, DEBUG log only be published in console. LOGback and SLF4J can be used.
Reporting is very important for automation. especially Web based reporting (html). Normally test framework provided it, but the look and feel is not good. So I recommend to use some 3rd party frameworks to do it. like ExtentReport or ReportNG.
Web UI test is most important for e2e test. We always need to trigger the work-flow from GUI, So we need Selenium Utilities to make test case development easier. If you are using POM(page-object-model), we can implement abstract page object, it can help us to initialize WebDriver object (for different browsers with different settings, plugins etc.), it can provide some basic UI operations like locate element by XPath/element attribute, take screenshot, then add it in report page etc.
For some complicated test, we need to query database to verify middle state of the test, or make some dummy data in the database as test prerequisite. this util can be initialized from Test Context.
Sometimes we need to do some CLI based test. the binary is deployed on remote host, so we need to execute the commands via SSH. for some SSL based endpoints, we need to disable hostname verification or access it with different protocol versions like TLS v1, v1.1, v1.2, There is open-source project JCABI can be used. Simple Java SSH Client
We always need to verify test result in test case code. How to make the step easier and simpler. I recommend 3rd party tool Hamcrest.
RESTful API is very popular in integrated system, micro services design, different component/system can communicate b/w each other very easy. So there is a test requirement to verify REST API or use it to make some changes in internal-system. We'd better to get a REST framework to implement this kind of test. I recommend to use REST-Assured.
In some use cases, user will be notified by email. So for e2e test, we need to verify whether the notification is received and then get some detailed info from the email body. Email Utils is useful here, we can use it to receive email from Mail Server via IMAP/POP3, and check Mime Body Part to get key info.
Container service is so popular in the world, it can provide a customized test environment for tester. So we'd better to use it launch Docker instance on Docker host to setup test environment and trigger the test defined in Docker image.
Finally, we need to create a base test class to integrate our test with different test framework like TestNG, JUnit. it will provide some basic test functionalities based on above utilities. All the test cases will be implemented based on it.
Common test runtime flow is like below
- Validate Test Env and Test Case Input Parameters (do some smoke tests)
- Run Test Case on Hudson/Jenkins master/slave or Docker host
- Validate Test Result
- Generate and publish test report
We can use Maven/Gradle to build test package and trigger the test. We can setup Nexus (maven proxy) server to deploy our utility artifacts.
We can store our test code in different branches, we can trigger our test from different versions. So we can use SVN, git as version control provider.