To help demonstrate the range of uses that Testers can put Java to in their projects, I have created a case study showing how Java skills can support technical testing of Java Desktop Apps.
The case study takes the form of a FREE set of videos that run for just over an hour in length.
In this case study you will see different approaches for applying a Technical Testing approach to a desktop Java Application.
Over the course of the videos we will use technical knowledge of Java, and apply it to a MORIM Technical Testing Model: Modelling, Observation, Reflection, Interrogation and Manipulation.
As a result we will explore different ways of observing and interrogating the running application. As we do so we will expand our model of the application and identify ways of manipulating the application.
Some of the things you will learn:
- different ways to start a Java Application and how that impacts your ability to observe
- how to wrap a Java App in a Java project to automate scenarios and explore the application using code
- how to manipulate a running Java application at low levels
- how risk impacts your testing and what to consider when testing technically
This course builds on skills and information developed in the book “Java For Testers”, so if you find this interesting, remember to check out JavaForTesters.com and EvilTester.com as well.
You can watch the first video below:
Why?
When we learn Java, or think about learning Java, we may have a limited model of the possibilities that the knowledge opens up for us.
As we learn we develop skills we may be unaware of:
- Use of IDE
- General Debugging Skills
- Breakpoint running code
- Inspect variables when debugging
- Running Java applications from the command line
- Ability to review Java Code
- Understanding exception messages
All of this can help us with our Technical Testing.
If you haven’t read Java For Testers yet, then this video series will give you an idea of the way that Testers can apply they Java knowledge they learn.
And if you have read Java For Testers, then this might reveal opportunities to expand your testing that you haven’t explored yet.
Source
I have released the source code github.com/eviltester/houseOfTestDataGenCaseStudy.
There isn’t too much to the source code. A single @Test method in an Test .java file.
The pom.xml was really just to create a basic project in IntelliJ to use the inbuilt IntelliJ decompiler.
The source code is the code used to ’test’ the random generation. This won’t work unless you add the data generation tool as a dependent jar as described in the case study videos.
And I haven’t done any work to tidy up the code so again it reflects a ‘write whatever code you need to get the job done’ attitude.
If I use the code more than once then I would revisit it, refactor it, etc. etc.
But I didn’t. I used it during the case study and now it lives on github).
