2015-01-26 5 views
-2

В моем классе я следующий открытый метод:Как написать единичный тест для одного метода линии (манекен)?

public boolean sendEmail(String[] recepients, String from, String subject, String templateName, 
          Map<String, Object> params) { 
     return sendMail(recepients, from, subject, templateName, null, params, null, null); 
    } 

Это просто работа делегации другим способом (частным).

Как я могу написать модульный тест для этого?

+3

ИМО, нет. Просто проверьте, что 'sendMail' принимает нулевые параметры. – immibis

+3

Что вы хотите точно проверить? –

+3

Боковое примечание: один метод, называемый 'sendEmail', и один метод, называемый' sendMail', звучит как плохая идея для меня. –

ответ

1

Независимо от того, имеет ли метод только делегирование другому (частному) методу или содержит его собственный код, не имеет значения при написании теста.

Хороший модульный тест подтверждает, что проверяемый блок выполняет свой контракт. Клиенты sendEmail не должны знать и не заботиться, если основная работа выполняется по частному или общедоступному методу.

Что такое (public версия) sendEmail Предполагается, что do? Это то, что должен проверить ваш модульный тест. Намек, что «направляет свои аргументы частного метода» не правильный ответ :)

+0

Я согласен, но это не ответ на мой вопрос. – gstackoverflow

+0

@gstackoverflow Ваш вопрос: «Как я могу написать модульный тест для этого?». Этот ответ, похоже, затрагивает этот вопрос. Если вы хотите получить более конкретный ответ, вы должны отредактировать свой вопрос, чтобы он был более конкретным. –

+0

@gstackoverflow, но серьезно, что делает частный метод? Я предполагаю, что он вызывает некоторые методы для какого-либо объекта службы SMTP. Если это так, вы должны ввести макет этой службы и убедиться, что правильные методы были вызваны правильно. – gustafc

0

В результате я написал следующий код:

@Mock 
EmailService emailServiceMock; 

@Test 
public void sendEmailTest() { 
    String[] recepients = new String[0]; 
    String from = "from"; 
    String subject = "subject"; 
    String templateName = "templateName"; 
    Map<String, Object> params = Collections.emptyMap(); 
    String nullString = null; 
    Integer nullInteger = null; 
    when(emailServiceMock.sendEmail(recepients, from, subject, templateName, params)).thenCallRealMethod(); 
    when(emailServiceMock.sendMail(recepients, from, subject, templateName, nullString, params, nullString, nullInteger)).thenReturn(true); 
    emailServiceMock.sendEmail(recepients, from, subject, templateName, params); 
    Mockito.verify(emailServiceMock).sendMail(eq(recepients), eq(from), eq(subject), eq(templateName), eq(nullString), eq(params), eq(nullString), eq(nullInteger)); 
} 
+0

Это не очень полезный тест IMHO. Все, что он делает, это проверка того, что один метод вызывает другой. Он не говорит вам, является ли метод правильным, и он будет ломаться с чрезвычайно простыми изменениями вашего частного метода. Другими словами, это «тест детектора изменений». См. Http://googletesting.blogspot.com/2014/05/testing-on-toilet-effective-testing.html и http://googletesting.blogspot.com/2015/01/testing-on-toilet-prefer-testing -public.html – NamshubWriter

+0

Google только что опубликовал запись в блоге об испытаниях детектора изменений: http://googletesting.blogspot.com/2015/01/testing-on-toilet-change-detector-tests.html – NamshubWriter