Develop Reference

How can a unit test "test the contract" on a method that returns void?

Java 8 here but this is a general unit testing question that (is likely) language-agnostic.
The syntax of writing a JUnit test is easy, but deciding on what tests to write and how to test main/production code is what I find to be the biggest challenge. In reading up on unit testing best practices, I keep hearing the same thing over and over again:
Test the contract
I believe the idea there is that unit tests should not be brittle and should not necessarily break if the method's implementation changes. That the method should define a contract of inputs -> results/outcomes and that the tests should aim to verify that contract is being honored. I think.
Let's say I have the following method:
public void doFizzOnBuzz(Buzz buzz, boolean isFoobaz) {
// wsClient is a REST client for a microservice
Widget widget = wsClient.getWidgetByBuzzId(buzz.getId());
if(widget.needsFile()) {
File file = readFileFromFileSystem(buzz.getFile());
if(isFoobaz) {
// Do something with the file (doesn't matter what)
}
}
return;
}
private File readFileFromFileSystem(String filename) {
// Private helper method; implementation doesn't matter here EXCEPT...
// Any checked exceptions that Java might throw (as a result of working)
// with the file system are wrapped in a RuntimeException (hence are now
// unchecked.
// Reads a file from the file system based on the filename/URI you specify
}
So here, we have a method we wish to write unit tests for (doFizzOnBuzz). This method:
Has two parameters, buzz and isFoobaz
Uses a class property wsClient to make a network/REST call
Calls a private helper method that not only works with the external file system, but that "swallows" checked exceptions; hence readFileFromFileSystem could throw RuntimeExceptions
What kinds of unit tests can we write for this that "test the contract"?
Validating inputs (buzz and isFoobaz) are obvious ones; the contract should define what valid values/states for each of those are, and what exceptions/results should occur if they are invalid.
But beyond that, I'm not really sure what the "contract" here would even be, which makes writing tests for it very difficult. So I guess this question really should be something like "How do I determine what the contract is for a unit test, and then how do you write tests that target the contract and not the implementation?"
But that title would be too long for a SO question.

Your code with the methods doFizzOnBuzz(Buzz buzz, boolean isFoobaz) and private File readFileFromFileSystem(String filename) is not easily testable, because the first method will try and read a file, and that's not something you want to do in test.
Here, doFizzOnBuzz needs something to provide a File for it to work with. This FileProvider (as I'll call it) could be an interface, something like:
public interface FileProvider {
File getFile(String filename);
}
When running in production, an implementation to actually read the file from disk is used, but when unit testing doFizzOnBuzz a mock implementation of FileProvider could be used instead. This returns a mock File.
The key point to remember is that when testing doFizzOnBuzz, we are not testing whatever provides the file, or anything else. We assume that to working correctly. These other bits of code have their own unit tests.
A mocking framework such as Mockito can be used a create mock implementations of FileProvider and File, and to inject the mock FileProvider into the class under test, probably using a setter:
public void setFileProvider(FileProvider f) {
this.fileProvider = f;
}
Also, I don't know what a wsClient is, bit I do know it has a getWidgetByBuzzId() method. This class too could be an interface, and for testing purposes the interface would be mocked, and return a mock Widget, similar to the FileProvider above.
With mockito, not only can you set up mock implementations of interfaces, you can also define what values are returned when methods are called on that interface: e.g.
//setup mock FileProvider
FileProvider fp = Mockito.mock(FileProvider.class);
//Setup mock File for FileProvider to return
File mockFile = Mockito.mock(File.class);
Mockito.when(mockFile.getName()).thenReturn("mockfilename");
//other methods...
//Make mock FileProvider return mock File
Mockito.when(fp.getFile("filename")).thenReturn(mockFile);
ClassUnderTest test = new ClassUnderTest();
test.setFileProvider(fp); //inject mock file provider
//Also set up mocks for Buzz,, Widget, and anything else
//run test
test.doFizzOnBuzz(...)
//verify that FileProvider.getFile() was actually called:
Mockito.verify(fp).getFile("filenane");
The above test fails if getFile() was not called with the parameter 'filename'
Conclusion
If you cannot directly observe the results of a method, e.g. it is void, you can use Mocking to verify its interaction with other classes and methods.

The problem is that your contract method does not tell what effect you can observe from the outside. It is basically a BiConsumer, so appart from ensuring there is an exception or not, there is not much unit testing possible.
The test you could do is to ensure that the (Mocked) REST service is called, or that the File (part of the Buzz parameter, which might be pointing to a temporary file) will be impacted by the method under some conditions.
If you want to unit test the output of the method, you may need to refactor to separate the determination of what should be done (file needs update) from actually doing it.

How to subclass SubethaSmtp SMTPClient class

I am trying to develop a simple SMTPclient for testing purposes using the SubethaSmtp client package. i want to use the SMTPClient class instead of the SmartClient class for more control but i have not been able to figure out how to write mail data using SMTPClient, the only OutputStream exposed to public or external subclasses is the one for sending commands, the ones for sending data (after sending the DATA command) is exposed only to classes in the same package (SmartClient).
am i missing something here? i would like to know how a direct subclass of SMARTClient can written to work around this problem.

Looks like you are correct, you cannot simply extend the SMTPClient and get access similar to the one that SmartClient has, being a same-package class.
At this point you can either:
1) Fork your own version of the app from https://github.com/voodoodyne/subethasmtp and do whatever the hell you like with it, or
2) Go all the way and implement your own version of SMTPClient, as the package protected SMTPClient.dotTerminatedOutput;, used by SmartClient.dataWrite() actually is just instantiated like so
...
this.rawOutput = this.socket.getOutputStream();
this.dotTerminatedOutput = new DotTerminatedOutputStream(this.rawOutput);
...

How to write unit tests for this simple application

I have an application with a class registered as a message listener that receives messages from a queue, checks it's of the correct class type (in public void onMessage(Message message)) and sends it to another class that converts this class to a string and writes the line to a log file (in public void handleMessage(MessageType m)). How would you write unit tests for this?

If you can use Mockito in combination with JUnit your test could look like this:
public void onMessage_Success() throws Excepton {
// Arrange
Message message = aMessage().withContent("...").create();
File mockLogFile = mock(File.class);
MessageHandler mockMessageHandler = mock(MessageHandler.class);
when(mockMessageHandler).handleMessage(any(MessageType.class)
.thenReturn("somePredefinedTestOutput");
when(mockMessageHandler).getLogFile().thenReturn(mockLogFile);
MessageListener sut = spy(new MessageListener());
Whitebox.setInternalState(sut, "messageHanlder", mockMessageHandler);
// or simply sut.setMessageHandler(mockMessageHandler); if a setter exists
// Act
sut.onMessage(message);
// Assert
assertThat(mockLogFile, contains("your desired content"));
verify(sut, times(1)).handleMessage(any(Message.class));
}
Note that this is just a simple example how you could test this. There are probably plenty of other ways to test the functionality. The example above showcaeses a typical builder-pattern for the generation of default-messages which accept certain values for testing. Moreover, I have not really clarified the Hamcrest matcher for the contains method on the mockLogFile.
As #Keppil also mentioned in his comment, it makes sense to create multiple test-cases which varry slightly in the arrange and assert parts where the bad-cases are tested
What I probably didn't explain enough is that getLogFile() method (which with high certainty has an other name in your application) of MessageHandler should return the reference to the file used by your MessageHandler instance to store the actual log-messages. Therefore, it probably is better to define this mockMessageHandler as spy(new MessageHandler()) instead of mock(MessageHandler.class) although this means that the unit-test is actually an integration test as the interaction of two classes is tested at the same time.
But overall, I hope you got the idea - use mock(Class) to generate default implementations for dependencies your system-under-test (SUT) requires or spy(Instance) if you want to include a real-world object instead of one that only has null-values as return types. You can take influence on the return-value of mocked objects with when(...).thenReturn(...)/.thenThrow(...) or doReturn(...).when(...) in case of void-operations f.e.
If you have dependency-injection into private fields in place you should use Whitebox.setInternalState(...) to inject the values into the sut or mock classes if no public or package-private (if you obtain the testing-model of reusing the package structure of the system-under-test classes within your test-classes) setter-methods are available.
Further, verify(...) lets you verify that a certain method was invoked while executing the SUT. This is quite handy in this scenario when the actual assertion isn't that trivial.

Wanted but not invoked: Mockito and Powermock

I have a Junit test that I inherited that is no longer working. It is using PowerMock 1.4.12, Mockito 1.9.0 and Junit 4.8.2. It was working awhile back but stopped and I am trying to get it to work again.
Wanted but not invoked:
clerkReviewPackageHelper.addSubmissionQueue(
<any>,
<any>,
<any>,
<any>
);
-> at icis.cr.approvefilingdetail.CRFilingToQueuesActionTest.test_post_handled_add_submission_queue(CRFilingToQueuesActionTest.java:47)
Actually, there were zero interactions with this mock.
at icis.cr.approvefilingdetail.CRFilingToQueuesActionTest.test_post_handled_add_submission_queue(CRFilingToQueuesActionTest.java:47)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:66)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:312)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:86)
at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:94)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.executeTest(PowerMockJUnit44RunnerDelegateImpl.java:296)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runBeforesThenTestThenAfters(PowerMockJUnit44RunnerDelegateImpl.java:284)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:84)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:49)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.invokeTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:209)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.runMethods(PowerMockJUnit44RunnerDelegateImpl.java:148)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$1.run(PowerMockJUnit44RunnerDelegateImpl.java:122)
at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:34)
at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.run(PowerMockJUnit44RunnerDelegateImpl.java:120)
at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.run(JUnit4TestSuiteChunkerImpl.java:102)
at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.run(AbstractCommonPowerMockRunner.java:53)
at org.powermock.modules.junit4.PowerMockRunner.run(PowerMockRunner.java:42)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Here is the code for this test:
#Test
public void test_post_handled_add_submission_queue() throws Exception {
when(request.getMethod()).thenReturn(BaseCRAction.POST);
when(sessionInfo.getSubmissionId()).thenReturn(SUBMISSION_ID);
when(crFilingToQueuesForm.getAction()).thenReturn(null);
crFilingToQueuesAction.executeProcess(actionMapping, crFilingToQueuesForm, request, response);
verify(clerkReviewPackageHelper, times(0)).removeSubmissionQueue(null);
**verify(clerkReviewPackageHelper).addSubmissionQueue(any(String.class), any(String.class), any(String.class), any(String.class));**
verify(actionMapping).findForward(eq(BaseCRAction.FORWARD_SUCCESS_REDIRECT));
}
And this is the method that it calls from the line in the exception:
public void addSubmissionQueue(String submissionId, String queueId, String reviewOn, String employeeId) throws BadDBConnection {
Session session = injector.inject();
session.executeNonSelectingCall(clerkReviewPackage.addQueue(submissionId, queueId, reviewOn, employeeId));
session.release();
}
Any help would be appreciated!
Thanks,
Tom

It looks like executeProcess used to call addSubmissionQueue but doesn't anymore, but without the code of executeProcess it's hard to say for sure.
If it's appropriate not to call addSubmissionQueue, you can simply delete the reference to that verification line. If it is important to call it, or call it under specific circumstances, edit the test so the verify line only happens in test cases where a call to that method is required.
Note that because Mockito is involved, your test isn't calling the actual code for addSubmissionQueue, but a mock instead. Read more about how Mockito works in the examples on the Mockito homepage.

Try :
import org.mockito.Mockito;
// ...
Mockito.verify(clerkReviewPackageHelper, Mockito.times(0)).addSubmissionQueue();

Your clerkReviewPackageHelper mock doesn't seem to be associated with your call to executeProcess in any way. It's not passed in, and it doesn't seem to be returned, directly or indirectly, from any method calls on any mocks that are passed in to executeProcess. It therefore hardly seems reasonable to expect one of its methods to get called by executeProcess.
What you need to do is look through the call to executeProcess and find the object, if any, on which addSubmissionQueue is called. Without seeing the code for executeProcess, I can't really offer assistance with this. It may be but there is no such method call, as #JeffBowman has conjectured in his answer. But there are also other possibilities.
If the object on which addSubmissionQueue is called is one of the parameters to executeProcess, then you should use clerkReviewPackageHelper as the corresponding argument in the test.
If the object on which addSubmissionQueue is called is an a field in the one of the parameters to the executeProcess, then inject clerkReviewPackageHelper, either in the constructor of crFilingToQueuesAction, or a setter, or even with #InjectMocks.
If the object on which addSubmissionQueue is called is obtained from a method call on one of the other parameters to executeProcess, then you need to make that call return clerkReviewPackageHelper. This might mean injecting that value into some object, or it might mean stubbing a method call on a mock. For example, if the method that you're testing obtains clerkReviewPackageHelper by calling a line like crFilingToQueuesForm.getHelper(), then you need to write when(crFilingToQueuesForm.getHelper()).thenReturn(clerkReviewPackageHelper); or something similar. It may turn out to be more complex than this of course. I can't tell without seeing your code.
If you need more help, then please post the code of your executeProcess method.

I also faced this issue while writing testcase for my controller method,what i missed is am passing the parameters to my test method those are declared but not initialized inside the setup method, so i did them in setup method and the issue fixed.

Android mock Camera

Is it possible to mock the Android Camera class ?
#Override
public void setUp() {
_camera = Mockito.mock(Camera.class);
}
fails to generate a mock (ExceptionInitializerError in Mockito's createProxyClass).
Should I create some kind of wrapper around the Camera (not my favorite solution, would really like to just mock the class...)?
Or, should I use a different mock library then Mockito?
Hope somebody can point me in the right direction.
Complete stacktrace of ExceptionInitializerError
java.lang.ExceptionInInitializerError
at org.mockito.internal.creation.jmock.ClassImposterizer.createProxyClass(ClassImposterizer.java:85)
at org.mockito.internal.creation.jmock.ClassImposterizer.imposterise(ClassImposterizer.java:62)
at org.mockito.internal.creation.jmock.ClassImposterizer.imposterise(ClassImposterizer.java:56)
at org.mockito.internal.creation.CglibMockMaker.createMock(CglibMockMaker.java:23)
at org.mockito.internal.util.MockUtil.createMock(MockUtil.java:26)
at org.mockito.internal.MockitoCore.mock(MockitoCore.java:51)
at org.mockito.Mockito.mock(Mockito.java:1243)
at org.mockito.Mockito.mock(Mockito.java:1120)
at com.cleancode.lifesaver.flashlight.test.FlashLightTests.setUp(FlashLightTests.java:20)
at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:190)
at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:175)
at android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:555)
at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1661)
Caused by: java.lang.VerifyError: org/mockito/cglib/core/ReflectUtils
at org.mockito.cglib.core.KeyFactory$Generator.generateClass(KeyFactory.java:167)
at org.mockito.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
at org.mockito.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:217)
at org.mockito.cglib.core.KeyFactory$Generator.create(KeyFactory.java:145)
at org.mockito.cglib.core.KeyFactory.create(KeyFactory.java:117)
at org.mockito.cglib.core.KeyFactory.create(KeyFactory.java:109)
at org.mockito.cglib.core.KeyFactory.create(KeyFactory.java:105)
at org.mockito.cglib.proxy.Enhancer.<clinit>(Enhancer.java:70)
... 18 more

The answer is late but here is a mock camera example for Android.
You can set the VideoFileInputSource to mock camera from video file
textureVideoInputSource = new VideoFileInputSource(this, "mock_input_video.mp4");
or you can enable hardware camera for video stream.
textureVideoInputSource = new CameraTextureVideoInputSource(this);
You can find the complete sample project here.
https://github.com/muneikh/MockCamera

In your stacktrace, notice the substring ".CglibMockMaker": that's the problem here. CGLib doesn't work on android -- there's a plugin for Mockito specifically for android that uses dexmaker, which is like CGLib but works for dalvik. Just search for dexmaker mockito and you should be on the right path.
You still won't be able to mock Camera.open() (the static factory method), but you can refactor your code around that. What matters is that Camera is not a final class; the rest is just awkward plumbing for the test, which you should just accept as the tax for writing well-tested android apps.

I think the ExceptionInInitializerError exception is happening because Camera is only supposed to be instantiated through its static open() method, so some kind of static initialization is failing when Mockito tries to create a mock. It doesn't seem to be possible to work around that. Perhaps it expects to interact with hardware that isn't present in a test environment? You may be able to use PowerMock to mock it anyway, or you may just want to go with your stated alternative of a wrapper class with an interface.