how to mock return value in robolectric

[Vipin Aravind]

Hi,

     I  have  some  code  like  this:-

bufferSize = AudioRecord.getMinBufferSize(RECORDER_SAMPLERATE,RECORDER_CHANNELS,RECORDER_AUDIO_ENCODING); Is there a way to mock the return value of getMinBufferSize using robolectric. Thanks

[Tyler Schultz]

It appears that no one has created a shadow for AudioRecord yet, so you'll have to start there. 

--Tyler

[Vipin Aravind]

Assume  there  is a  shadow  object.  let  us  take  MediaRecorder  for  example.

How  do  you  tell  Robo  that  I  want  certain  method to  return  a  value  like  we  do  with  mockito and  other  mock  frameworks.

[Tyler Schultz]

If you'd like to do mockito style mocking, you should use that, Robolectric should play fine.  Me personally? I'm not a fan of that style of testing, but that's just my opinion.

Let's take the MediaRecorder.getAudioSourceMax() as an example. A pattern we very often use is to put a setter method on the shadow class to set values that will be returned.

@Implements(MediaRecorder.class)
public class ShadowMediaRecorder {

    ...

    private static int audioSourceMax;

    @Implementation
    public static int getAudioSourceMax() {
        return audioSourceMax;
    }

    /* non-Android setter */

    public static void setAudioSourceMax(int audioSourceMax) {

        this.audioSourceMax = audioSourceMax;

    }

    ...

}

You'd need to set the value to be returned in your test's setup by invoking the method on the shadow.

@RunWith(WithTestDefaultsRunner.class)

public class MediaRecorderTest {

...

    public void setUp() {

        ShadowMediaRecorder.setAudioSourceMax(42);

    }

    public void testMaxAudio() {

       assertThat(MediaRecorder.getAudioSourceMax(), equalTo(42));

    }

}

One last thing to note here is that we're using the static. This will cause test pollution, so you need to do teardown.  We make a point to do this type of cleanup in one place:

public class Robolectric {

    ...

    public static void resetStaticState() {

        ...

        ShadowMediaRecorder.reset();

    }

    ...

}

--Tyler

[Gal Ben-Haim]

what's so different between this approach and the Mockito approach for this scenario ?

[Levi]

I believe what Tyler is referring to (please correct me if I'm wrong) is the difference between classicists and mockists as described in Martin Fowler's article "Mocks Aren't Stubs" (http://martinfowler.com/articles/mocksArentStubs.html). I'm not sure that either approach is wrong, but it's important to know the difference and to be aware of the pitfalls of each style.

[Tyler Schultz]

Robolectric clouds this discussion. It's doing all sorts of whacky stuff (bytecode manipulation, resource parsing, to name a few...) under the covers making your tests run slower than they might otherwise. One of my complaints about easy mock and mockito is the slow speed at which the tests run, but tests written with Robolectric are fairly heavy weight themselves. I will say that if you are using Robolectric that mocking Android will only make your tests run slower.

One argument I like to make against mocking is the setup. Setup in Robolectric is not simple, but once it's done, all other users of Robolectric have the setup that I've created (reuse). I've not seen a codebase where the use of mocking framework mocks are shared in this way (anecdote alert!). I have a harder time coming up to speed on a given test where mocks are used. I feel like Robolectric helps by adding a separation of concern - faking out Android (Robolectric) and testing the application's behavior (your application test).

--Tyler