Harish Blogs

The intention of this example is not to encourage running unit or integration test in a specific in the build. Instead this is a powerful and handy way to reproduce random build failure due to test clashing with each other or lack of isolation between tests. The fundamental idea is to temporarily create a junit platform suite and run the tests in the same order which caused the build failure and reproduce the failure in a consistent and deterministic way. Once the failure can be reliably reproduced, the clashing test can be easily narrowed down. In order to create this sample suite, we need the following test dependency: group id: org.junit.platform artifact id: junit-platform-suite version: <<latest>> Create a sample Junit suite and run it using your favourite IDE. package com.harishkannarao.test; import org.junit.platform.suite.api. SelectClasses ; import org.junit.platform.suite.api. Suite ; @Suite // order of the test classes is very important. E.g ExampleTest runs firs...

I was looking to improve my integration test suite, which contains large number of integration test (more than 900 test cases). My immediate focus was to tackle the slowest running tests in my test suite. TestNG reports provide the information of slowest running test out of the box, however my project was using JUnit 4. Being a lazy developer, I didn't want to migrate my entire test suite to TestNG in order to get reports about slowest running test. Hence I was looking at other options available in JUnit test framework. JUnit offers a Rule called stopwatch, which notifies us the time taken to complete each test as callback methods. However, most of the examples showed how to print the information on console or some logger. Printing on the console or logger is particularly not very helpful, as it doesn't allow us to analyse the data in an easy way. Hence I had created a custom stopwatch rule which extends JUnit's stopwatch rule and capture the information provided by ...