Increasing Testability - Adding Interfaces and Mocks | CodeSignal Learn

Increasing Testability - Adding Interfaces and Mocks | CodeSignal Learn

Introduction

Welcome to the third lesson of the Increasing Code Test Coverage course! In our previous lessons, we explored the importance of code test coverage and how characterization tests can help document existing behavior. Now, we will focus on increasing testability by using traits and mocks . This lesson will guide you through the process of decoupling dependencies, which is crucial for writing effective and reliable tests. By the end of this lesson, you'll understand how to refactor code to make it more testable and how to use Mockito's mocking capabilities to create mock objects for testing.

Understanding the Problem

Testing code with tightly coupled dependencies can be challenging. When a class directly depends on external services, such as email or database services, it becomes difficult to isolate the code under test. This can lead to unreliable and non-repeatable tests. For instance, if our OrderProcessor class directly calls an EmailService to send confirmation emails, testing the OrderProcessor without actually sending emails becomes problematic. The goal is to isolate the code under test to ensure that our tests are reliable and repeatable, while not triggering side effects and not depending on logic that isn't being tested directly.

Introducing Traits

Traits play a crucial role in decoupling dependencies. By defining a trait, you create a contract that different implementations can adhere to. This allows you to substitute real implementations with test doubles, such as mocks or stubs, during testing. For example, instead of directly using an EmailService in our OrderProcessor, we can define an EmailService trait. This trait can then be implemented by the EmailService class. Here's the EmailService in question: Scala class EmailService: def sendOrderConfirmation(order: Order): Unit = println("[Sending Email] This should not happen in tests!") This class can be adjusted to adhere to a trait that defines the contract for the relevant class: Scala trait EmailService: def sendOrderConfirmation(order: Order): Unit object RealEmailService extends EmailService: override def sendOrderConfirmation(order: Order): Unit = println("[Sending Email] This should not happen in tests!") By using the EmailService trait, we can easily swap out the real EmailService with a mock during testing, allowing us to test the OrderProcessor without sending actual emails.

Sign up

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Implementing Mocks with Mockito

Mocks are a type of test double that allows you to simulate the behavior of real objects. Mockito provides capabilities for creating mock objects. It enables you to define how a mock should behave and verify interactions with it. For example, we can use Mockito to create a mock of the EmailService and verify that the sendOrderConfirmation method is called during the processOrder method of the OrderProcessor . Here's how you can set up a mock using Mockito : import org.scalatest.funspec.AnyFunSpec import org.scalatestplus.mockito.MockitoSugar import org.mockito.Mockito.* class OrderProcessorSpec extends AnyFunSpec with MockitoSugar: describe("OrderProcessor"): it("should call sendOrderConfirmation when processing an order"): // Arrange val mockEmailService: EmailService = mock[EmailService] val orderProcessor: OrderProcessor = OrderProcessor(mockEmailService) val order: Order = Order(List(OrderItem(BigDecimal(10.00), 1))) // Act orderProcessor.processOrder(order) // Assert verify(mockEmailService).sendOrderConfirmation(order) In this example, we create a mock of the EmailService . This allows us to use any code that requires the EmailService trait with full control over what happens when calling members of said trait.

Refactoring Code for Testability

Refactoring code to use traits and mocks can significantly enhance testability. Let's walk through the process of refactoring the OrderProcessor class to accept an EmailService trait. The initial implementation could look something like this: class OrderProcessor: private val emailService = RealEmailService def processOrder(order: Order): Boolean = // ... order processing logic ... // Send confirmation email emailService.sendOrderConfirmation(order) true With our trait defined above, we can now create a more testable implementation using a companion object: object OrderProcessor: def apply(emailService: EmailService = RealEmailService): OrderProcessor = new OrderProcessor(emailService) class OrderProcessor private (emailService: EmailService): def processOrder(order: Order): Boolean = // ... order processing logic ... emailService.sendOrderConfirmation(order) true By using the EmailService trait and a companion object with an apply method, the OrderProcessor can now work with any implementation of the trait, making it more flexible and easier to test. The private constructor ensures that instances are created through the companion object, providing a clean API for creating new instances.

Scala

import org.scalatest.funspec.AnyFunSpec
import org.scalatestplus.mockito.MockitoSugar
import org.mockito.Mockito.*

class OrderProcessorSpec extends AnyFunSpec with MockitoSugar:
  describe("OrderProcessor"): 
    it("should call sendOrderConfirmation when processing an order"): 
      // Arrange
      val mockEmailService: EmailService = mock[EmailService]
      val orderProcessor: OrderProcessor = OrderProcessor(mockEmailService)
      val order: Order = Order(List(OrderItem(BigDecimal(10.00), 1)))

      // Act
      orderProcessor.processOrder(order)

      // Assert
      verify(mockEmailService).sendOrderConfirmation(order)

Scala

class OrderProcessor:
  private val emailService = RealEmailService

  def processOrder(order: Order): Boolean =
    // ... order processing logic ...

    // Send confirmation email
    emailService.sendOrderConfirmation(order)

    true

Scala

object OrderProcessor:
  def apply(emailService: EmailService = RealEmailService): OrderProcessor =
    new OrderProcessor(emailService)

class OrderProcessor private (emailService: EmailService):
  def processOrder(order: Order): Boolean =
    // ... order processing logic ...
    emailService.sendOrderConfirmation(order)
    true