Android PointF constructor not working in JUnit test

Question

I have just stumbled on this while trying to write a JUnit test. Admittedly this is my first unit test in JUnit, but I do find the behaviour very puzzling.

package com.example.dom.pointfbugrepro;

import android.graphics.PointF;
import org.junit.Test;
import static org.junit.Assert.*;

public class ExampleUnitTest {
    @Test
    public void pointf_isCorrect() throws Exception {
        PointF foo = new PointF(5, 0);
        assertEquals(5, foo.x, 0.0001f);
    }
}

Running this test in a brand new Android Project results in an assertion failure:

java.lang.AssertionError: 
Expected :5.0
Actual   :0.0

One thing I found out while investigating this problem is that assigning to the PointF instance's x field directly does work.

So what is the problem here? Why doesn't the constructor set the fields properly? and how should I be testing classes which use the PointF Android class?

Answer 1

See http://tools.android.com/tech-docs/unit-testing-support#TOC-Method-...-not-mocked.-

When you run unit tests, you are using a dummy version of the android jar. Typically you will see "Method ... not mocked."exceptions, but since you are directly accessing public fields, these are simply default values.

Depending on your requirements, you could just use a fake: your own subclass extending PointF

    public static class FakePointF extends PointF {
        FakePointF(float x, float y) {
            this.x = x;
            this.y = y;
        }
    }

but in a more complex test you'll probably end up having to mock a whole lot of other methods.

The solution isnt pretty: you need to run instrumented tests against an emulator or device, or move to using something like Robolectric where the test runner will substitute 'shadows' for you.

Also see this StackOverflow answer: android.graphics.Point: all methods are stubs.

Answer 2

I was really surprised that some classes do behave like this in JUnit tests. I don't see any good reason for this in case of a simple DTO class like Point, but rather consider this as a nasty Easter egg which makes programmers' life harder. I would accept that methods like Draw etc. are mocked, as they can be heavily hardware-dependent, but such DTO's should not be mocked.

I'm still learning Android development, but the more such things I see the more I'm convinced that it is not a mature and well-thought framework.