public class SenderService {
private JmsOperations jmsTemplate;
public void doSend(final MyMessage myMessage){
jmsTemplate.send(new MessageCreator() {
public Message createMessage(Session session) throws JMSException {
return session.createObjectMessage(myMessage);
}
});
}
}
Pytanie jest dość podchwytliwe, gdyż uważam, że testy jednostkowe bardzo dobrze się sprawdzają do testowania logiki systemu. Kod powyżej nie ma jakiejś extra rozbudowanej logiki, ale jest ona dość dobrze zakopana. Poza tym wychodząc od TDD (jak przykazane) jak mogło dojść, że mamy kod a teraz zastanawiamy się jak go przetestować ?
Tworzenie testów na tym etapie wydaję się sensowne jedynie w celach regresji.
Z drugiej strony można się upierać, czy jest sens aby ten kod testować jednostkowo, czy nie testować go jedynie integracyjnie. Takie podejście wydaje się zgodne z tym co można wyczytać w http://www.growing-object-oriented-software.com/ a powyższy kod leżałby w warstwie adaptera zgodnie z Ports and Adapters pattern. Jednakże, z pragmatycznego punktu widzenia (albo wtedy gdy w ogóle nie mamy automatycznych testów integracyjnych/systemowych) przetestowanie jednostkowo powyższego kodu jest jak najbardziej możliwe.
Najpierw zastanowiłbym się co chcemy przetestować, bo w metodzie send dzieją się 2 rzeczy: wywołanie JMSTemplate.send oraz pośrednio budowa JMS Message. Najsensowniejsze wydaje się rozdzielenie obu funkcjonalności i przetestowanie ich osobno. Zacznijmy od testowania budowania JMS Message za pomocą jednego z dwóch podejść:
- tworzymy top level class implementującą MessageCreator
public class MyMessageCreator implements MessageCreator {
private final MyMessage message;
public MyMessageCreator(MyMessage message) {
this.message = message;
}
@Override
public Message createMessage(Session session) throws JMSException {
return session.createObjectMessage(message);
}
} - tworzymy factory
MessageCreator getMessageCreator(final MyMessage message) {
return new MessageCreator() {
@Override
public Message createMessage(Session session) throws JMSException {
return session.createObjectMessage(message);
}
};
}
}
Dzięki temu możemy w stosunkowo łatwy sposób przetestować, że nasz kod poprawnie tworzyJMS message (na potrzebę testów użyjemy mocków/stubów)
Następnie, możemy sprawdzić czy nasza metoda send faktycznie użyje jmsTemplate.send z odpowiednie parametrem. Taki test będzie zależał od tego w jaki sposób zaimplementowaliśmy tworzenie JMS Message. Jeśli stworzyliśmy własną klasę MessageCreator to możemy sprawdzić czy parametr metody send jest właśnie jej typu. Ewentualnie można użyć (gruba rura!) PowerMock. W drugim przypadku będziemy mogli zamockować factory. Jeśli rolę fabryki pełni osobna klasa (potencjalnie ukryta pod interfejsem) to nie wydaję się to najgorsze (nie licząc tego że powstały nam kolejne artefakty), a w przypadku gdy fabryką będzie lokalna metoda to już wchodzimy w tematy partial-mocking.
Gdybyśmy jednak chcieli podany kod przetestować bez jego uprzedniej refaktoryzacji, czyli bez wprowadzania podziału na: budowania JMS message i wywołanie jmsTemplate, to też jest to jak najbardziej możliwe. Sprawa wydaje się stosunkowo prosta: należy sprawdzić czy metoda jmsTemplate.send jest wywołana z odpowiednim parametrem. Odpowiedni parametr to taki, który jak wywołamy na nim metodę send
to na przekazanej JMS session zostaną wywołane odpowiednie metody. Poniżej przykłady jak to zostało zrobione za pomocą EasyMock i Mockito
public class SenderServiceEasyMockTest {
private SenderService sut = new SenderService();
private JmsOperations jmsOperations;
private MyMessage myMessage = new MyMessage("neverMind");
@Before
public void setUp() {
jmsOperations = EasyMock.createMock(JmsOperations.class);
sut.setJmsTemplate(jmsOperations);
}
@Test
public void testDoSendByArgumentMatcher() {
final Session session = EasyMock.createMock(Session.class);
IArgumentMatcher argumentMatcher = new IArgumentMatcher() {
public boolean matches(Object argument) {
MessageCreator messageCreator = (MessageCreator) argument;
try {
EasyMock.expect(session.createObjectMessage(myMessage))
.andReturn(null);
EasyMock.replay(session);
messageCreator.createMessage(session);
} catch (JMSException e) {
throw new RuntimeException(e);
}
return true;
}
public void appendTo(StringBuffer buffer) {
}
};
EasyMock.reportMatcher(argumentMatcher);
jmsOperations.send((MessageCreator) null);
EasyMock.replay(jmsOperations);
sut.doSend(myMessage);
EasyMock.verify(jmsOperations, session);
}
@Test
public void testDoSendByCapture() throws JMSException {
Capture<Messagecreator> tocapture = new Capture();
jmsOperations.send((MessageCreator) EasyMock.and(EasyMock.anyObject(),
EasyMock.capture(tocapture)));
EasyMock.replay(jmsOperations);
sut.doSend(myMessage);
MessageCreator value = tocapture.getValue();
Session session = EasyMock.createMock(Session.class);
EasyMock.expect(session.createObjectMessage(myMessage)).andReturn(null);
EasyMock.replay(session);
value.createMessage(session);
EasyMock.verify(jmsOperations, session);
}
}
public class SenderServiceMockitoTest {
private SenderService sut = new SenderService();
private JmsOperations jmsOperations;
private MyMessage myMessage = new MyMessage("SSSS");
@Before
public void setUp() {
jmsOperations = Mockito.mock(JmsOperations.class);
sut.setJmsTemplate(jmsOperations);
}
@Test
public void testDoSendByMatcher() {
sut.doSend(myMessage);
Mockito.verify(jmsOperations).send(Mockito.argThat(new ArgumentMatcher<Messagecreator>() {
@Override
public boolean matches(Object argument) {
MessageCreator messageCreator = (MessageCreator) argument;
Session session = Mockito.mock(Session.class);
try {
messageCreator.createMessage(session);
Mockito.verify(session).createObjectMessage(myMessage);
} catch (JMSException e) {
throw new RuntimeException(e);
}
return true;
}
}));
}
@Test
public void testDoSendByCaptor() throws JMSException {
sut.doSend(myMessage);
ArgumentCaptor<Messagecreator> messaArgumentCaptor = ArgumentCaptor.forClass(MessageCreator.class);
Mockito.verify(jmsOperations).send(messaArgumentCaptor.capture());
Session session = Mockito.mock(Session.class);
MessageCreator value = messaArgumentCaptor.getValue();
value.createMessage(session);
Mockito.verify(session).createObjectMessage(myMessage);
}
}
Pomimo braku jakiegokolwiek refaktoringu testy w EasyMock wyglądają o wiele mniej czytelniej od tych napisanych w Mockito. Wynika to głównie z potrzeby wołania w odpowiednich miejscach EasyMock.replay oraz (co gorsze) braku mechanizmów do weryfikacji zachowań, które zaszły w ramach wywołania metody podległej testowi. W przypadku EasyMock jest potrzeba wyspecyfikowania a priori wszystkich interakcji, a w Mockito możemy wygodnie użyć Mockito.verify. Szczególnie w tym przypadku bardzo wpływa to na czytelność kodu, gdy sekcje given/when/then sa zaburzone. Dodatkowo użycie mechanizmu capture w obu przypadkach wydaję się być zdecydowanie wygodniejsze od użycia argumentMatcher
