Working with legacy code is difficult.
When working with legacy code, you can run into a number of challenges, like for instance : how to write a unit test for a method that contains a hidden, private dependency.
Let me show you an example of such code :
public class NotificationService {
private void sendSMSNotification(User user, Event event, boolean isUrgent) throws NotificationException {
try {
String messageContent = buildSMSMessageContent(user, event, isUrgent);
String phoneNumber = user.getPhoneNumber();
if (phoneNumber == null || phoneNumber.isEmpty()) {
throw new NotificationException("User's phone number is not available.");
}
// Get SmsService bean from ApplicationContext
SmsService smsService = ApplicationContextHolder.getBean(SmsService.class);**
boolean isSent = smsService.sendSMS(phoneNumber, messageContent);
if (!isSent) {
throw new NotificationException("Failed to send SMS to " + phoneNumber);
}
// Optionally log the SMS sending for auditing purposes
logSMSSending(user, phoneNumber, messageContent, isUrgent);
} catch (Exception e) {
throw new NotificationException("Error occurred while sending SMS notification.", e);
}
}
}
Here the hidden dependency is the SmsService. As you can see, it is instantiated with the Spring ApplicationContext.
This is a common pattern we can “encounter” when working with a legacy code. The idea behind this ApplicationContextHolderis that it serves as a “utility” class that has a reference to the Spring applicationContext and instead of injecting the bean, or the service with @Autowired we are directly injecting by calling the static method ApplicationContext.getBean .
This is problematic because SmsService is hidden, private and is making a real Api call to the the SmsProvider.
In my test, I want to have the possibility to mock the SmsService.
So, how to achieve that ?
Extract and override getter
There is a technique that Michael Feathers describes in his book Working effectively with Legacy Code to overcome this problem. It’s called Extract and Override getter .
To expose the SmsService, define a getter, getSmService and use that getter in all places where the SmService is used in the class. This getSmsService visibility is protected.
public class NotificationService {
private void sendSMSNotification(User user, Event event, boolean isUrgent) throws NotificationException {
try {
//same as before
SmsService smsService = getSmsService();
boolean isSent = smsService.sendSMS(phoneNumber, messageContent);
if (!isSent) {
throw new NotificationException("Failed to send SMS to " + phoneNumber);
}
// same as before
}
protected SmsService getSmsService(){
return ApplicationContextHolder.getBean(SmsService.class);
}
}
2nd step, create a TestNotificationService that will override the getSmsService and return a FakeSmsService.
class TestNotificationService extends NotificationService {
@Override
public SmsService getSmsService(){
return new FakeSmsService();
}
}
For the sake of simplicity, let’s imagine that SmsService is an interface, otherwise you would need to extract an interface from the SmsService that will contain sendSms as a method.
The FakeSmsService will return false for the sendSms method.
class FakeSmsService implements SmsService {
@Override
public boolean sendSms(phoneNumber, messageContent){
return false;
}
}
And then write your test.
@Test
void test_raise_an_exception_when_sms_is_not_sent(){
NotificationService notificationService = new TestNotificationService();
Exception exception = assertThrows(NotificationException.class, () -> {
notificationService.sendSMSNotification(user, event, false);
}
Assertions.assertEquals("Failed to send SMS to 0606060606", exception.getMessage());
}
To summarize
- Create a getter to expose with protected visibility
- Define a test class that extends the main and overrides the getter previously defined.
- Use it your test.
Top comments (0)