Now for the real work: building out the integration between SoundViewModel and your new BeatBox.play(Sound) method. A common way to go about this is to write a test that shows what you expect a new method to do before you have written the method. You are going to write a new method on SoundViewModel called onButtonClicked() that calls BeatBox.play(Sound). Write a test method that calls onButtonClicked().

    @Test
    public void exposesSoundNameAsTitle() {
        assertThat(mSubject.getTitle(), is(mSound.getName()));
    }

    @Test
    public void callsBeatBoxPlayOnButtonClicked() {
        mSubject.onButtonClicked();
    }
}

That method does not exist yet, so it shows up in red. Put your cursor over it and key in Option+Return (Alt+Enter). Then select Create method 'onButtonClicked' and the method will be created for you.

    public void setSound(Sound sound) {
        mSound = sound;
        notifyChange();
    }

    public void onButtonClicked() {

    }
}

For now, leave it empty and key in Command+Shift+T (Ctrl+Shift+T) to return to SoundViewModelTest.

Your test calls the method, but it should also verify that the method does what you say it does: calls BeatBox.play(Sound). Mockito can help you do this odd-sounding job. All Mockito mock objects keep track of which of their methods have been called as well as what parameters were passed in for each call. Mockito’s verify(Object) method can then check to see whether those methods were called the way you expected them to be called.

Call verify(Object) to ensure that onButtonClicked() calls BeatBox.play(Sound) with the Sound object you hooked up to your SoundViewModel.

        assertThat(mSubject.getTitle(), is(mSound.getName()));
    }

    @Test
    public void callsBeatBoxPlayOnButtonClicked() {
        mSubject.onButtonClicked();

        verify(mBeatBox).play(mSound);
    }
}

The verify(Object) uses a fluent interface, much like the AlertDialog.Builder class you used earlier in this book. It is an abbreviation for the following code:

verify(mBeatBox);
mBeatBox.play(mSound);

Calling verify(mBeatBox) says, “I am about to verify that a method was called on mBeatBox.” The next method call after that is then interpreted as, “Verify that this method was called like this.” So your call to verify(…) here means, “Verify that the play(…) method was called on mBeatBox with mSound as a parameter.”

No such thing has happened, of course. SoundViewModel.onButtonClicked() is empty, so mBeatBox.play(Sound) has not been called. This means that your test should fail. Because you are writing the test first, that is a good thing – if your test does not fail at first, it must not be testing anything.

Run your test to see it fail. You can follow the same steps from earlier, or key in Command+R (Ctrl+R) to repeat the last “Run” command you performed. The result is shown in Figure 21.6.

Figure 21.6  Failing test output

The output says that your test expected a call to mBeatBox.play(Sound) but did not receive it:

Wanted but not invoked:
beatBox.play(
    com.bignerdranch.android.beatbox.Sound@64cd705f
);
-> at ….callsBeatBoxPlayOnButtonClicked(SoundViewModelTest.java:28)
Actually, there were zero interactions with this mock.

Under the hood, verify(Object) made an assertion, just like assertThat(…) did. When that assertion failed, it caused the test to fail and logged out this output describing what went wrong.

Now to fix your test. Implement onButtonClicked() to do what the test expects.

    public void setSound(Sound sound) {
        mSound = sound;
        notifyChange();
    }

    public void onButtonClicked() {
        mBeatBox.play(mSound);
    }
}

Rerun your test. This time you should see green, indicating that all your tests passed (Figure 21.7).

Figure 21.7  All green, all good