Я бы предложил изменить область действия метода private
на package
или protected
. Затем вы можете переопределить его в тестовом классе, который расширяет ваш класс.
Я бы не пытался имитировать все службы, используемые в методе sendMail
, потому что тогда ваш тест будет зависеть от всего в sendMail
метод, даже если он не нужен. В результате ваш тест должен быть изменен всякий раз, когда изменяется внутренняя часть метода sendMail
. Это было бы плохо, потому что вашему тесту не нужен метод sendMail
- вот почему вы хотите имитировать его.
Ваш тест также станет очень сложным со всеми имитами, которые необходимы только для того, чтобы sendMail
метод работает.
Намного лучше было бы извлечь метод sendMail в интерфейс и создать реализацию с содержимым текущего метода sendMail.
public interface ChecklistNotifier {
public void sendNotification(Checklist checklist);
}
public class EmailChecklistNotifier implements ChecklistNotifier {
public void sendNotification(Checklist checklist){
EmailService emailService = new EmailService();
BaseDTO esDO = newFolderService.getFolderByUri(ServicesUtils.getDecodedCaseNodeUriFromSelfLink(Checklist.getEs_uri()));
// ...
}
}
Ваш клиент Затем класс может использовать ChecklistNotifier
.
public class ClientClass {
private ChecklistNotifier notifier;
public ClientClass(ChecklistNotifier notifier){
this.notifier = notifier;
}
public void method(Checklist checklist){
/*Some Code*/
notifier.sendnotification(checklist);
/*Some Code*/
}}
}
Теперь вы можете легко создать экземпляр ClientClass
в своем тесте и передать ему ChecklistNotifier
макет или простую реализацию.
Этот подход также учитывает принципы SOLID, потому что
- единственная ответственность как за
ClientClass
, так и за EmailChecklistNotifier
- он открыт-закрывается - вы можете заменить его макетом или другими реализациями, возможно, SMS-уведомление
- отдельный интерфейс - ChecklistNotification
- инвертировал зависимость и, следовательно, развязал
ClientClass
из зависимостей реализации отправки почты.