testing private method

[Wendy L Gibbons]

i have 2 methods:

@DELETE
	@Path("/")
	public Response completeDiaryEvents(int uniqueId, String resolutionCode)
		throws CdiRouterException
	{
		DiaryEntry diaryEntry = loadDiaryEntryImpl(uniqueId, false); // goes off to a service
		UpdateEntry update = mapDiaryEntryToUpdateEntry(diaryEntry);
		update.setResolutionCode(resolutionCode);
		update.setUniqueID(uniqueId);
		
		UpdateResponse updateResponse = m_diaryService.update(update); //the same service again
		TypeResponseStatus status = updateResponse.getStatus();
		if(status.compareTo(TypeResponseStatus.SUCCESS) == 0)
		{
			return Response.ok().build();
		}
		return Response.serverError().build();
	}

	private UpdateEntry mapDiaryEntryToUpdateEntry(DiaryEntry diaryEntry)
	{
		UpdateEntry update = new UpdateEntry();
		update.setCompleteDate(new Date());
		update.setActionCode(diaryEntry.getActionCodeEntity().getCode());
		Entry entry = diaryEntry.getEntry();
		update.setActionDate(entry.getActionDate()); 
		update.setDocCode(entry.getDocCode());
		update.setDocLineNum(entry.getDocLineNum());
		update.setDocNum(entry.getDocNum());
		update.setPriority(entry.getPriority());
		update.setReasonCode(entry.getReasonCode());
		update.setResponsibleUser(entry.getResponsibleUser());
		update.setTaskDescription(entry.getTaskDescription());
		return update;
	}

so the only logic is the private mapper method, i have 3 options for testing this which is better
1) make the method protected
2) make it a mapper class
3) spy on the variables sent to the diaryService.update method.

i suppose there is option 4, refactor the code to remove this whole problem, but I have no idea how that could be done.

[Junilu Lacar]

how about an update entry builder with a buildFrom(DiaryEntry) method? You can test that pretty cleanly. I would start with a builder class that is package private in scope too.

[Geroen Joris]

Well, I guess there's also option 5:
- using PowerMockito, mock the constructor calls
- check the calls on the mocks
- call the private method via reflection

Option 6 comes to mind too: make the method package local, and access it that way in your test (given that your test is in the same package)

[Sagar Rohankar]

I recommend Junilu answer, remember if you're mocking private methods, there is something wrong with your design.

Secondly, if you're already stuck in legacy code base or don't want to touch/alter current code, try Mockito Argument Matcher on m_diaryService.update(update);, if you can mock m_diaryService.

[Geroen Joris]

I'm not talking about mocking, I'm talking about accessing. And I have been in the same situation - after having used "extract method" enough in your IDE to separate the different levels of abstraction.

I do, however, tend to agree with you in this case. The builder is the better option. The private method doesn't seem to contains something that's to be considered private to this class.