Every once in a while you might encounter a flaky unit test. I know, unit tests can’t be flaky by definition … but also life comes in the way, so sometimes it happens. Such a test will consistently pass on most developer machines, but fail in a CI environment every once in a while. In this post I’ll share how I go about fixing such problems.
read more
Ideally automated tests should be predictable, isolated and precise, allowing you to find an issue quickly. If these conditions are met, you’ll never have to change a test unless to accommodate a changed requirement. This sounds great on paper, but in practice we often forget the isolated bit and start testing multiple things in a single test. If abused, we’ll end up with tests that need updating all the time, causing developer frustration and wasting time.
One tool that can help with isolation of tests is using matchers. As the name suggests, matchers allow you to match an object agains certain conditions.
read more
Here’s a few handy commands if you want to run only a specific unit test(s). Suppose we have the following unit tests in the project:
./gradlew test – run unit tests for all variants
./gradlew testDebug – run tests for Debug variant
./gradlew testDebug --tests="*.helpers.*" – run all tests in the helpers package
./gradlew testDebug --tests="*.HelperTest" – run all tests in HelperTest.java class
./gradlew testDebug --tests="*.getHelp" – run only the getHelp test method.
read more