A few months back, I was going through some posts related to Test Automation in Quora. Suddenly a question posted by an anonymous user caught my attention – “What is Maven in Selenium?”.
This was not the first time I came across this question or similar questions during my journey as an SDET. This is quite common since there is a lot of confusion regarding the differences between the build automation tools (“Maven” is one of them), and the test automation libraries, mostly among the testers who have just started learning/working on Test Automation and came across build tools for the first time.
I felt it is a must to discuss the importance of Build Management Tools and discuss how learning and understanding the core concepts behind the Build Tools help us in our day-to-day life as testers in this Modern Testing age.
With the gradual movement towards Continuous Integration and Continuous Delivery (CI/CD) and DevOps mindset, open-source build automation tools have become an integral part of the software application development and test automation framework development processes.
“Build Automation” is a term which, in general, is referred to anything that helps us to script and automate the repetitive tasks needed to “set-up” a software product – collecting all the assets to be included, automating all the tasks to compile-build-test-package the source code and automated deployments to different environments. Thereby making our life easier as developers and allowing us to focus more on other important tasks like creation and debugging.
Since Test automation Framework Development itself is a Development activity, where all the development best practices and principles are needed to be followed to create a production-ready software (which in this case is our Test Automation framework), it’s not a surprise that the Build Tools play a crucial role here too.
I have observed in some of the small-scale test automation initiatives that build tools were not used, and the related activities were done manually. That’s fine, but for a Test Automation framework that supports or plans to support multiple projects, have multiple developers working on it and requires reliable maintenance and scaling – it is imperative to use Build Tools which are highly customizable, easy to set up and cost nothing.
Below are some of the benefits that build tools offer to make our life as developers easier.
Managing Dependencies
Managing project dependencies, through the processes of declaring, resolving and using those dependencies in an automated way, might be considered the most important task that the build tools perform for our test automation frameworks.
Dependencies are the reusable functionalities that we use in our frameworks in the form of language libraries or third-party modules. They can be anything – a single file, a collection of files organized into packages, external libraries (in web), internal libraries (in company-specific corporate repositories like nexus or artifactory), other projects and jars that are present on the network somewhere and those dependencies are needed to be resolved.
Consider your framework uses Selenium, Appium, Rest-Assured libraries along with some other libraries like Junit/TestNG, Apache POI, log4j, Cucumber etc. Now, going forward you want to use the latest version/any other specific version of the log4j library. If done manually, you have to remove the existing log4j jar file, download the version from a central or corporate repository and add to your project. Also, you need to inform the other developers of your team to do the same so that their builds do not fail when you push your changes to the source control. Sometimes, dependencies themselves depend on other dependencies (Transitive Dependencies) which are also needed to be downloaded and added.
Most build tools have flexible dependency configurations in the form of configuration files (like pom.xml, build.gradle) which we can modify. Build Tools will automatically create a local repository (a local structure), download the declared dependencies once (along with their transitive dependencies), cache them, re-download them if required and refer them from that location in future.
Provides Structure to the Project
Organizing the automation framework in a convenient and meaningful way enables the test automation developers to easily understand the framework codebase, responsibility of each folder, hierarchy of concepts within and how they are related to each other. In my project, it helped us to write solid, clean, scalable code by separating out the business logic, tests, reports, resources, data, configuration details, utilities and the core framework implementation. By default, some of the build tools provide a bunch of standard build conventions which we can use while performing the builds and tests. This allows other developers to understand the project structure and find their way around. Some build tools will also allow you to reconfigure the default conventions by overriding them and use your own. We can even customize and define separate directories for different test types like unit tests, smoke tests, functional tests and integration tests. The unit testing frameworks (like Junit) can automatically find the right classes to test without us having to specify imports for them.
Powerful Plugins Support
Each of the build tools have a collection of powerful software add-ons or tools which can provide additional behavior on top of their existing capabilities. Those are the Build Tool Plugins. Knowingly or unknowingly, most of you might already be using those plugins in your day-to-day tasks (remember surefire plugin of Maven?). Some of the plugins are core to the build tools and perform the core tasks, whereas some customized plugins can be used to perform customized tasks according to our needs.
The plugins help us to automate various tasks such as copying/zipping/renaming files, restructuring folders, opening files and modifying the text inside, validating the project structure, performing static code analysis, cleaning up previous builds, compiling the source code and performing a fresh build, compiling and running tests, generating reports and documentations, creating, assembling and packaging artifacts/libraries/executables with metadata, installing them in our local repository or deploying them to a remote repository to help other teams use our test automation framework.
Support in Continuous Integration
With the widespread adoption of the DevOps culture, organizations are trying to create, improve and release products at a faster pace and some of them have already started making efforts to move towards a Whole Team Approach where everyone participates in the successful delivery of a product.
In such an agile environment where changes are continuously integrated and continuously delivered (CI/CD), all the repetitive tasks which are done manually need an automation intervention. The build tools integrate well with the CI systems like Jenkins, Hudson, Bamboo, TeamCity, TravisCI, etc.
Once we change and check-in our test automation code in the source control system, then the CI systems can automatically check-out that change and trigger jobs to build and test the code with the help of build tools integrated into it. If the build is successful, they can generate artifacts and publish them to repositories for others to use.
Conclusion
In addition to the above benefits, the build tools work well with our IDEs and can also be used standalone from the command line. Though the IDEs themselves have the capabilities to build the projects and create artifacts, the build tools are more powerful when it comes to automating those tasks and customization, as per the project need, with the help of JSON, XML or scripting languages like Groovy or simple shell scripts.
Moreover, some of the build tools have the concept of “Wrappers” (which I find amazing) using which we can define the specific version of build tool to use to build the project without any dependency on the build tool version installed in our system. This leads to consistent builds across different development environment, developer machines or CI systems.
Though it is true that you can quickly set up a build environment with the help of the build tools, it will take some time for your team to visualize their real benefits in your automation framework, once you start tweaking little things to perform certain tasks. They will definitely provide a consistent streamlined process that everyone in your team can follow and ultimately it will lead to a better test automation framework product.