Why Should Testers Start Learning Build Management Tools?
Why Should Testers Start Learning Build Management Tools?
Take a look at some of the benefits that developers can reap by using build management tools, and get some clarification on what they do.
Join the DZone community and get the full member experience.Join For Free
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. This makes 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 and multiple developers working on it, it 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 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.
Imagine 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 also need to be downloaded and added.
Most build tools have flexible dependency configurations in the form of configuration files (like pom.xml or 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, the responsibility of each folder, the hierarchy of concepts within, and how they are related to each other. In my project, it helped us to write solid, clean, and 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 has 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. 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. They also assist in validating the project structure, performing static code analysis, cleaning up previous builds, compiling the source code, and performing a fresh build.
Supporting 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, and TravisCI.
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.
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.
Published at DZone with permission of Sumon Dey , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.