Profile a Java unit test (very quickly, with no external tools)

I have a unit test that is running slowly, and I want a quick view of what is happening.

I can get a nice overview of where the code spends its time by adding this to the JVM arguments:

-agentlib:hprof=cpu=samples,lineno=y,depth=3,file=hprof.samples.txt

and running the test as normal.

Now I can look at the file that was created, hprof.samples.txt, and looking at the bottom section I can see how much time is spent in each method.

This worked for me within IntelliJ IDEA community edition by clicking “Run” then “Edit Configurations” and adding the above code to “VM options” for my test.

It should also work in Gradle by editing gradle.properties and adding something like this:

org.gradle.jvmargs=-agentlib:hprof=cpu=samples,lineno=y,depth=3,file=hprof.samples.txt

and should also work in Maven. In fact, I found this information in this stackoverflow question: How do you run maven unit tests with hprof?.

Make Android Gradle display unit test failure messages

By default, Gradle does not show you what happened when a unit test failed:

$ ./gradlew test
...
MyTest > Black_is_white FAILED
    org.junit.ComparisonFailure at MyTest.java:6
    ^^^ WHAT ACTUALLY FAILED????
...

This is insane, and can be fixed (thanks to mrhaki) by editing build.gradle to add:

// NOTE: this is the non-Android solution - add to build.gradle
test {
    testLogging {
        exceptionFormat = 'full'
    }
}

The above doesn’t work with Android, but something similar does:

// Android solution: add this to app/build.gradle
android.testOptions.unitTests.all {
    testLogging {
        exceptionFormat = "full"
    }
}

And sanity prevails:

$ ./gradlew test
...
MyTest > Black_is_white FAILED
    org.junit.ComparisonFailure:
    expected:<[black]> but was:<[white]>
        at org.junit.Assert.assertEquals(Assert.java:115)
        at org.junit.Assert.assertEquals(Assert.java:144)
        at MyTest.Black_is_white(MyTest.java:6)
...

Files for plain Gradle:

$ cat build.gradle
apply plugin: 'java'

repositories {
    mavenCentral()
}
     
dependencies {
    testCompile 'junit:junit:[4,)'
}

test {
    testLogging {
        exceptionFormat = 'full'
    }
}

$ cat src/test/java/MyTest.java
public class MyTest
{
    @org.junit.Test
    public void Black_is_white()
    {
        org.junit.Assert.assertEquals("black", "white");
    }
}

Files for Android+Gradle

$ cat build.gradle
buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:2.3.1'
    }
}

allprojects {
    repositories {
        jcenter()
    }
}

$ cat app/src/main/AndroidManifest.xml
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="net.artificialworlds.testapp">
</manifest>

$ cat app/src/test/java/MyTest.java
public class MyTest
{
    @org.junit.Test
    public void Black_is_white()
    {
        org.junit.Assert.assertEquals("black", "white");
    }
}

$ cat build.gradle
buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:2.3.1'
    }
}

allprojects {
    repositories {
        jcenter()
    }
}

$ cat local.properties
sdk.dir=/home/andy/Android/Sdk

$ cat settings.gradle
include ':app'

Writing a unit test in Elm

Series: Snake in Elm, Elm makes me happy, Elm Basics, Elm Unit Test, Elm JSON

I’ve been having fun with Elm programming recently. Elm is a replacement for JavaScript that is pure functional and highly practical.

Here’s how to go from nothing installed at all to writing a unit test that passes, in just over 10 minutes.

The source code is here: github.com/andybalaam/elm-unit-test-example

Code for detecting when you leave an Android app

Further to Detecting whether an Android app is stopping (or starting), I implemented code to decide when you are leaving or entering my game Rabbit Escape.

The relevant class is called Lifecycle2SoundEvents. (Yes, it’s a terrible name. Yes, I spent a long time trying to name it, and this is the best I came up with.)

And the tests, which are in TestLifecycle2SoundEvents, look like this:

@Test
public void Press_the_home_button_api10_causes_pause()
{
    Tester t = new Tester( activity1 );

    t.in.onSaveInstanceState( activity1 );
    t.in.onPause( activity1 );
    t.in.onStop( activity1 );

    // When we press home, we must at least pause (really we stop)
    t.assertPaused();
}

which I was reasonably pleased with, because they match my original blog post Order of Android Activity lifecycle events fairly well, without too much noise.

Mocks are Bad, Layers are Bad

In which I argue that mocks are a code smell, and layers lead to increased coupling:

Mocks are Bad, Layers are Bad (in ACCU‘s Overload Journal issue 127)

I also suggest some ways to avoid both mocks and layers, including Classical TDD, Selfish Object, Refactor to Functional and, of course, the Unix Philosophy. I work through a code example to demonstrate some of these things.

I also suggest that frameworks and inheritance hierarchies are bad, but the title was getting too long already.

You can also get the PDF of Overload 127.