TLDR; We can use JUnit to execute code to support any type of testing.
Question:
Hi, you use Junit in the book “Java For Testers” and I thought JUnit was used for “unit testing” and “unit testing” was performed by developers , not testers. Is the purpose to learn JUnit and “unit testing” or other types of testing as well? In other words, would you recommend learning “java for Testers” to software testers who would rather not be involved in “unit testing” but rather involved in “system and UAT”?
Q: Is JUnit just for Unit Testing or can we use it for other testing as well? from Alan Richardson on Vimeo.
Answer:
JUnit is used for unit testing. And it is used for other types of testing as well.
I don’t think of JUnit as a Unit Testing Tool. Instead, I view it as a way of running code marked as ‘runnable by JUnit’. That code is marked by @Test annotations and is often called a Test, and those ‘Tests’ are often used for Unit testing, but they don’t have to be.
JUnit can be used as a test runner for any kind of test: e.g. system and integration tests; tests which are interacting with a deployed application.
e.g. the WebDriver tests here all use JUnit github.com/eviltester/seleniumWebDriverCompendium/tree/main/webDriverExperiments and they interact with an application which runs in a browser.
And you can see me use JUnit it here to aid my interactive exploratory and system testing of an API:
The name JUnit should not lead you to think that it is only for Unit testing.
If you want to automate, from code, then you’ll need some way of executing the code. In the book we use JUnit as Test Runner to execute code.
I see a lot of examples of “how to learn Java” which use ‘main’ methods to allow execution of the code.
‘main’ methods are a good approach if you want to compile your code into an application.
Unfortunately I’ve seen that when people learn to write Java this way, they often have multiple ‘main’ methods in their code, without really knowing why a ‘main’ method is are used. And they don’t learn any strategies for running bits of code in an adhoc fashion, as well as a strategic fashion.
In the book “Java For Testers” I wanted people to learn Test Driven Development, but not make it a ’thing’ just a natural process, so all the execution capabilities of the code are provided by @Test annotation, and executed from JUnit. This allows us to:
- Tactically Run arbitrary code without create main methods or packaging the app
- Use any library, not just for Unit testing, but also for Testing that integrates with deployed applications e.g. Web or API
- Strategically create suites which we can use longer term
- Unit test the abstraction layers and support code that we write so that we do Unit test, our System and Integration test code
- Easily add our code into a continuous integration approach
Hopefully as you work through the book that will all become clearer.
If you want to automate, you will need to write code, and you’ll want to unit test that code as well, and you’ll use JUnit for that, as well as using JUnit to provide the ability to execute your code.
I rarely unit test the applications I work on as a tester, but I do unit test the code I write to automate those applications as part of my testing.
Hope that makes sense.
P.S. I think you are unlikely to strategically automate as part of a UAT process. But you might tactically automate (adhoc) data setup and configuration, and you’ll need coding skills to do that effectively.
