Monday, 8 August 2016

How to convert a breakpoint into a conditional breakpoint in IntelliJ

TLDR; right click on a breakpoint and add code that returns a boolean to make it a conditional breakpoint

Breakpoints are great. You find the section of code that you want to investigate. Click on the side of the screen to create a breakpoint. Run the code in debug and it stops where you want it.

But what if you only wanted to stop on that breakpoint sometimes.

What do you do?

Add a watch, then when the code stops at the breakpoint, look at the watch and if it is not what you want, carry on?

Well that’s one way.

The other way is a conditional breakpoint.

A breakpoint that only triggers when a certain condition is set.

Let’s have a look.

I have this test.

And it fails!

java.lang.ArrayIndexOutOfBoundsException: 16

    at com.javafortesters.chap009arraysiteration.exercises.

well, it fails on something when it is 16.

Is it i==16 or is it row==16?

I know. I’ll convert the breakpoint to a conditional breakpoint and find out.

To create a conditional breakpoint I simply right click on the breakpoint symbol and type in a condition.

The condition is any adhoc Java code that will compile in the context of the breakpoint, and return a Boolean.

So I could make the ‘Condition’ i==15 then the breakpoint should only trigger when i equals 15.

Now when the breakpoint fires, I only have to step over once to get to the point where my code throws its error.

Rather than having to step through the loop 15 times.

Worth trying?

Tuesday, 2 August 2016

Is JUnit only for unit testing? What about system testing or UAT?

TLDR; We can use JUnit to execute code to support any type of testing.


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.


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 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.