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
On Sun, Sep 30, 2012 at 5:16 AM, Vipin Aravind <vipina...@gmail.com> wrote:
> 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
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.
On Sunday, September 30, 2012 7:34:56 PM UTC+5:30, Tyler Schultz wrote:
> It appears that no one has created a shadow for AudioRecord yet, so you'll > have to start there.
> --Tyler
> On Sun, Sep 30, 2012 at 5:16 AM, Vipin Aravind <vipi...@gmail.com<javascript:> > > wrote:
>> 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
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;
}
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();
}
...
On Sun, Sep 30, 2012 at 8:45 AM, Vipin Aravind <vipina...@gmail.com> wrote:
> 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.
> On Sunday, September 30, 2012 7:34:56 PM UTC+5:30, Tyler Schultz wrote:
>> It appears that no one has created a shadow for AudioRecord yet, so
>> you'll have to start there.
>> --Tyler
>> On Sun, Sep 30, 2012 at 5:16 AM, Vipin Aravind <vipi...@gmail.com> wrote:
>>> Hi,
>>> I have some code like this:-
>>> bufferSize = AudioRecord.getMinBufferSize(R**ECORDER_SAMPLERATE,
>>> RECORDER_**CHANNELS,RECORDER_AUDIO_**ENCODING); Is there a way to mock
>>> the return value of getMinBufferSize using robolectric. Thanks
On Sunday, September 30, 2012 8:10:36 PM UTC+2, Tyler Schultz wrote:
> 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; > }
> 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
> On Sun, Sep 30, 2012 at 8:45 AM, Vipin Aravind <vipi...@gmail.com<javascript:> > > wrote:
>> 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.
>> On Sunday, September 30, 2012 7:34:56 PM UTC+5:30, Tyler Schultz wrote:
>>> It appears that no one has created a shadow for AudioRecord yet, so >>> you'll have to start there.
>>> --Tyler
>>> On Sun, Sep 30, 2012 at 5:16 AM, Vipin Aravind <vipi...@gmail.com>wrote:
>>>> Hi, >>>> I have some code like this:- >>>> bufferSize = AudioRecord.getMinBufferSize(R**ECORDER_SAMPLERATE >>>> ,RECORDER_**CHANNELS,RECORDER_AUDIO_**ENCODING); Is there a way to >>>> mock the return value of getMinBufferSize using robolectric. Thanks
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.
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).
On Mon, Oct 1, 2012 at 4:48 AM, Levi <l...@leviwilson.com> wrote:
> 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.
