Объект тестирования, который вызывает другой объект в Scala с использованием Specs2

Если вы можете изменить код для Worker, вы можете изменить его, чтобы он по-прежнему оставался объектом, а также разрешить замену службы базы данных через implicit с определением по умолчанию. Это одно из решений, и я даже не знаю, возможно ли это для вас, но вот оно:

case class MyObj(id:Long)

trait DatabaseService{
  def getById(id:Long):Option[MyObj] = {
    //some impl here...
  }
}

object DatabaseService extends DatabaseService


object Worker{
  def doSomething(id:Long)(implicit dbService:DatabaseService = DatabaseService):Option[MyObj] = {
    dbService.getById(id)
  }
}

Итак, мы установили трейт с конкретным внедрением метода getById. Затем мы добавляем object реализацию этого трейта в качестве единичного экземпляра для использования в коде. Это хороший шаблон, позволяющий имитировать то, что ранее было определено только как object. Затем мы заставляем Worker принимать implicit DatabaseService (признак) в своем методе и присваиваем ему значение по умолчанию object DatabaseService, чтобы при обычном использовании не приходилось беспокоиться об удовлетворении этого требования. Затем мы можем протестировать это так:

class WorkerUnitSpec extends Specification with Mockito{

  trait scoping extends Scope{
    implicit val mockDb = mock[DatabaseService]
  }

  "Calling doSomething on Worker" should{
    "pass the call along to the implicit dbService and return rhe result" in new scoping{
      mockDb.getById(123L) returns Some(MyObj(123))
      Worker.doSomething(123) must beSome(MyObj(123))
    }
  }

Здесь, в моей области, я делаю доступным неявный фиктивный DatabaseService, который заменит DatabaseService по умолчанию в методе doSomething для моих целей тестирования. Как только вы это сделаете, вы можете начать издеваться и тестировать.

Обновить

Если вы не хотите использовать неявный подход, вы можете переопределить Worker следующим образом:

abstract class Worker(dbService:DatabaseService){
  def doSomething(id:Long):Option[MyObj] = {
    dbService.getById(id)
  }   
}

object Worker extends Worker(DatabaseService)

А затем протестируйте его так:

class WorkerUnitSpec extends Specification with Mockito{

  trait scoping extends Scope{
    val mockDb = mock[DatabaseService]
    val testWorker = new Worker(mockDb){}
  }

  "Calling doSomething on Worker" should{
    "pass the call along to the implicit dbService and return rhe result" in new scoping{
      mockDb.getById(123L) returns Some(MyObj(123))
      testWorker.doSomething(123) must beSome(MyObj(123))
    }
  }
}

Таким образом, вы определяете всю важную логику в абстрактном классе Worker, и это то, на чем вы до сих пор фокусируете свое тестирование. Вы предоставляете синглтон Worker через объект, который используется в коде для удобства. Наличие абстрактного класса позволяет вам использовать параметр конструктора, чтобы указать, какую службу базы данных следует использовать. Это семантически то же самое, что и предыдущее решение, но оно чище, поскольку вам не нужны неявные значения для каждого метода.