Running TestNG tests can be done in two ways: either directly from the IDE (by selecting the desired tests and choosing to ‘Run TestNG tests’) or from the command line. The latter option is very useful when trying to run only a selection of all the tests, that might spread across different classes or packages, or to run tests that belong to certain groups. To do this, you need to create some .xml files that will select the tests that need to run and/or exclude tests not to run, add a configuration in the Maven profile created for running the tests, and run the proper Maven command. Continue reading Running TestNG tests →
Like this:
Like Loading...
After the project has been created, you will need to decide how you want your automated tests to run. Keeping in mind that developers write unit tests, which by definition will validate of the code by itself, without interaction with other components, they are suitable to validate that the code commited satisfies the requirements in isolation. They should run fast, and not need interaction with browsers for example.
On the other hand, acceptance tests, which are the tests written by QAs should validate the code in the actual environment where it will reside, having contact with all the components around it. These tests validate that the code still acts properly when it runs in the system that it is built in. For that reason, these tests might take a long time to run, use browser instances, and might be rather fragile when it comes to succeeding. For example, Selenium tests are some of the most fragile, since, if you run tests in some sluggish environment, they might fail because of the slow responsiveness of the environment, pages not loading on time, and so on. Hence, running these tests for every project compilation phase is not feasible, as the build might never compile successfully. Continue reading Create the Maven profile for running tests. →
Like this:
Like Loading...
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 →
Like this:
Like Loading...
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 →
Like this:
Like Loading...
Testing. With Java, Selenium, TestNG, Maven, Spring, IntelliJ and friends.
