Most of the times your automation code project travels around, from machine to machine, to where the tests inside it need to run. Sometimes it might be your colleague’s machine, who also wants to run/update/add tests, but other times it will be some CI/CD entities, like physical or virtual machines, containers, and so on.
Continue reading Artifacts to store in your test automation project
If you haven’t seen, this week i released my series of 2 articles to help get you started with Maven. In the first one, i discuss how to setup Maven on your machine and how to create a brand new Maven project. I also explain key concepts that define what Maven and a Maven project are (like dependencies). Check out this article here: https://blog.testproject.io/2021/06/28/getting-started-with-maven-part-1/.
In the second installment in this series, i further discuss some specifics about dependencies. Then, i go over project goals, how you can run your tests, and how you can create profiles and use system properties in your test run. Check it out here: https://blog.testproject.io/2021/06/28/getting-started-with-maven-part-2/. Enjoy.
Coding standards are something both automating testers and developers should adhere to. Pretty obvious right? Maybe not that obvious might be some of the rules you should follow when writing the code for your tests. Checkstyle is here to help in standardizing your code, so that you can get an early feedback regarding code improvements (earlier than the code review step anyway). It allows you to define a set of basic coding rules that must be followed in your project, and it gives you the opportunity to make your builds fail if someone breaks those rules. This post addresses using checkstyle from a Maven project, by means of the dedicated Maven plugin that you need to declare in your project. Continue reading Using Maven checkstyle in your project to help adhere to coding standards
The central and most essential part of a Maven project is its’ pom.xml file. Among other information (like the project’s defining artifactID and groupID), it stores the list of dependencies your project has and the plugins the project will use. Dependencies that are declared within the pom.xml file will be downloaded from the Maven repository configured for the project, into the project, as external libraries or dependencies. The default repository that is configured is the Maven central repository (http://search.maven.org/#search|ga|1|), and except for the situation where you explicitly configure a local repository, this is the place to look for the latest versions of the libraries you will import into your project. Continue reading Import the testing dependencies
As a best practice, tests will reside in the same project as the code that they test. Also, ideally, they should be written in the same programming language as the code itself. If the code is Java, it’s useless to come up with some different language or so called framework to test it. Developers write Junit or TestNG tests, why shouldn’t QA’s do the same? The language itself offers most of what you need for testing, and where it doesn’t, there are plenty of libraries you can use to help out, that can easily be imported into the project. There is vast knowledge around, so if you are in doubt there are numerous people to turn to for advice. Also, it’s better if the developer and QA speak the same language. Developers can give you input regarding best practices for writing code, so that your tests can be easily readable by any member of the project team, maintainable, effective.
Having said that, if you are the one who will create the project, you can do it quite easily, using Maven. Continue reading Create a new Maven project
imalittletester 