Packages

  • package root

    This is the documentation for ScalaMock

    ScalaMock

    This is the documentation for ScalaMock

    For an overview, see org.scalamock.

    Definition Classes
    root
  • package org
    Definition Classes
    root
  • package scalamock

    To use ScalaMock, you need the relevant MockFactoryBase trait implementation:

    ScalaMock: Native Scala Mocking

    To use ScalaMock, you need the relevant MockFactoryBase trait implementation:

    At present, ScalaMock can only mock traits, Java interfaces, and non-final classes that define a default constructor. A future version will be able to mock any class, and singleton/companion objects.

    ScalaMock supports two different mocking styles - expectations first and record then verify. These styles can be mixed within a single test.

    Expectations-First Style

    In the expectations-first style, expectations are set on mock objects before exercising the system under test. If these expectations are not met, the test fails.

    A mock function that supports this style is created with mockFunction. For example, to create a mock function taking a single Int argument and returning a String:

    val m = mockFunction[Int, String]

    A mock object that supports this style is created with mock. For example, to create a mock that implements the Turtle trait:

    val m = mock[Turtle]

    Expectations can then be set using expects:

    (m.setPosition _).expects(10.0, 10.0)
(m.forward _).expects(5.0)
(m.getPosition _).expects().returning(15.0, 10.0)

drawLine(m, (10.0, 10.0), (15.0, 10.0))

    Record-then-Verify (Mockito) Style

    In the record then verify style, expectations are verified after the system under test has executed.

    A stub function that supports this style is created with stubFunction. For example:

    val m = stubFunction[Int, String]

    A stub object that supports this style is created with stub. For example:

    val m = stub[Turtle]

    Return values that are used by the system under test can be set up by using when. Calls are verified using verify:

    (m.getPosition _).when().returns(15.0, 10.0)

drawLine(m, (10.0, 10.0), (15.0, 10.0))

(m.setPosition _).verify(10.0, 10.0)
(m.forward _).verify(5.0)

    Argument matching

    ScalaMock supports two types of generalised matching: wildcards and epsilon matching.

    Wildcards

    Wildcard values are specified with an * (asterisk). For example:

    m expects ("this", *)

    will match any of the following:

    m("this", 42)
m("this", 1.0)
m("this", null)
    Epsilon matching

    Epsilon matching is useful when dealing with floating point values. An epsilon match is specified with the ~ (tilde) operator:

    m expects (~42.0)

    will match:

    m(42.0)
m(42.0001)
m(41.9999)

    but will not match:

    m(43.0)
m(42.1)
    Repeated parameters

    Repeated parameters are represented as a Seq. For example, given:

    def takesRepeatedParameter(x: Int, ys: String*)

    you can set an expectation with:

    (m.takesRepeatedParameter _).expects(42, Seq("red", "green", "blue"))
    Predicate matching

    More complicated argument matching can be implemented by using where to pass a predicate:

    m = mockFunction[Double, Double, Unit]
m expects (where { _ < _ })
    Return values

    By default mocks and stubs return null. You can return a computed return value (or throw a computed exception) with onCall:

    val mockIncrement = mockFunction[Int, Int]
m expects (*) onCall { _ + 1 }
    Overloaded, curried and polymorphic methods

    Overloaded, curried and polymorphic methods can be mocked by specifying either argument types or type parameters. For example:

    trait Foo {
  def overloaded(x: Int): String
  def overloaded(x: String): String
  def overloaded[T](x: T): String
  def curried(x: Int)(y: Double): String
  def polymorphic[T](x: List[T]): String
}
    val m = mock[Foo]
(m.overloaded(_: Int)).expects(10)
(m.overloaded(_: String)).expects("foo")
(m.overloaded[Double] _).expects(1.23)
(m.curried(_: Int)(_: Double)).expects(10, 1.23)
(m.polymorphic(_: List[Int])).expects(List(1, 2, 3))
(m.polymorphic[String] _).expects("foo")
    Exceptions

    Instead of a return value, mocks and stubs can be instructed to throw:

    m expects ("this", "that") throws new RuntimeException("what's that?")
    Call count

    By default, mocks and stubs expect exactly one call. Alternative constraints can be set with repeat:

    m1.expects(42).returns(42).repeat(3 to 7)
m2 expects (3) repeat 10

    There are various aliases for common expectations and styles:

    m1.expects("this", "that").once
m2.expects().returns("foo").noMoreThanTwice
m3.expects(42).repeated(3).times

    For a full list, see org.scalamock.handlers.CallHandler.

    Ordering

    By default, expectations can be satisfied in any order. For example:

    m expects (1)
m expects (2)
m(2)
m(1)

    A specific sequence can be enforced with inSequence:

    inSequence {
  m expects (1)
  m expects (2)
}
m(2) // throws ExpectationException
m(1)

    Multiple sequences can be specified. As long as the calls within each sequence happen in the correct order, calls within different sequences can be interleaved. For example:

    inSequence {
  m expects (1)
  m expects (2)
}
inSequence {
  m expects (3)
  m expects (4)
}

m(3)
m(1)
m(2)
m(4)

    To specify that there is no constraint on ordering, use inAnyOrder (there is an implicit inAnyOrder at the top level). Calls to inSequence and inAnyOrder can be arbitrarily nested. For example:

    (m.a _).expects()
inSequence {
  (m.b _).expects()
  inAnyOrder {
    (m.c _).expects()
    inSequence {
      (m.d _).expects()
      (m.e _).expects()
    }
    (m.f _).expects()
  }
  (m.g _).expects()
}

    Threads

    ScalaMock will work with tests that are run in parallel (Specs2 runs tests in parallel by default, and ScalaTest does so with ParallelTestExecution).

    You can call mocks from other threads within tests, but any such calls must be complete before the test completes - it's an error to call a mock afterwards.

    Definition Classes
    org
  • package clazz
    Definition Classes
    scalamock
  • package context
    Definition Classes
    scalamock
  • package function
    Definition Classes
    scalamock
  • package handlers
    Definition Classes
    scalamock
  • package matchers
    Definition Classes
    scalamock
  • package proxy
    Definition Classes
    scalamock
  • package scalatest
    Definition Classes
    scalamock
  • package proxy
  • AbstractAsyncMockFactory
  • AbstractMockFactory
  • AsyncMockFactory
  • AsyncMockFactoryBase
  • MixedMockFactory
  • MockFactory
  • PathMockFactory
  • package specs2
    Definition Classes
    scalamock
  • package util
    Definition Classes
    scalamock
p

org.scalamock

scalatest

package scalatest

Linear Supertypes
AnyRef, Any

Type Members

  1. trait AbstractAsyncMockFactory extends AsyncTestSuiteMixin with AsyncMockFactoryBase with AsyncTestSuite
  2. trait AbstractMockFactory extends TestSuiteMixin with MockFactoryBase with TestSuite
  3. trait AsyncMockFactory extends AbstractAsyncMockFactory with Mock with AsyncTestSuite
  4. trait AsyncMockFactoryBase extends MockContext with Mock with MockFunctions with Matchers
  5. trait MixedMockFactory extends AbstractMockFactory with Mock

    allows combining of macro mocks wih proxy mocks in the same Suite

    allows combining of macro mocks wih proxy mocks in the same Suite

    val macroMock = mock[Foo]
val proxyMock = Proxy.mock[Bar]
  6. trait MockFactory extends AbstractMockFactory with Mock with TestSuite

    Trait that can be mixed into a ScalaTest suite to provide mocking support.

    Trait that can be mixed into a ScalaTest suite to provide mocking support.

    class CoffeeMachineTest extends FlatSpec with ShouldMatchers with MockFactory {

	"CoffeeMachine" should "not turn on the heater when the water container is empty" in {
	    val waterContainerMock = mock[WaterContainer]
	    (waterContainerMock.isEmpty _).expects().returning(true)
	    // ...
	}

	it should "not turn on the heater when the water container is overfull" in {
	    val waterContainerMock = mock[WaterContainer]
	    // ...
	}
}

    Sharing mocks across test cases

    Sometimes multiple test cases need to work with the same mocks (and more generally - the same fixtures: files, sockets, database connections, etc.). There are many techniques to avoid duplicating the fixture code across test cases in ScalaTest, but ScalaMock recommends and officially supports these two:

    • isolated tests cases - clean and simple, recommended when all test cases have the same or very similar fixtures
    • fixture contexts - more flexible, recommened for complex test suites where single set of fixtures does not fit all test cases
    Isolated test cases

    If you mix OneInstancePerTest trait into a Suite, each test case will run in its own instance of the suite class and therefore each test will get a fresh copy of the instance variables.

    This way in the suite scope you can declare instance variables (e.g. mocks) that will be used by multiple test cases and perform common test case setup (e.g. set up some mock expectations). Because each test cases has fresh instance variables different test cases do not interfere with each other.

    // Please note that this test suite mixes in OneInstancePerTest
class CoffeeMachineTest extends FlatSpec with ShouldMatchers with OneInstancePerTest with MockFactory {
	// shared objects
	val waterContainerMock = mock[WaterContainer]
	val heaterMock = mock[Heater]
	val coffeeMachine = new CoffeeMachine(waterContainerMock, heaterMock)

	// you can set common expectations in suite scope
	(waterContainerMock.isOverfull _).expects().returning(true)

	// test setup
	coffeeMachine.powerOn()

	"CoffeeMachine" should "not turn on the heater when the water container is empty" in {
	    coffeeMachine.isOn shouldBe true
	    // ...
	    coffeeMachine.powerOff()
	}

	it should "not turn on the heater when the water container is overfull" in {
	    // each test case uses separate, fresh Suite so the coffee machine is turned on
	    coffeeMachine.isOn shouldBe true
	    // ...
	}
}
    Fixture contexts

    You can also run each test case in separate fixture context. Fixture contexts can be extended and combined and since each test case uses different instance of fixture context test cases do not interfere with each other while they can have shared mocks and expectations.

    class CoffeeMachineTest extends FlatSpec with ShouldMatchers with MockFactory {
	trait Test { // fixture context
	    // shared objects
	    val waterContainerMock = mock[WaterContainer]
	    val heaterMock = mock[Heater]
	    val coffeeMachine = new CoffeeMachine(waterContainerMock, heaterMock)

	    // test setup
	    coffeeMachine.powerOn()
	}

	"CoffeeMachine" should "not turn on the heater when the water container is empty" in new Test {
	    coffeeMachine.isOn shouldBe true
	    (waterContainerMock.isOverfull _).expects().returning(true)
	    // ...
	}

	// you can extend and combine fixture-contexts
	trait OverfullWaterContainerTest extends Test {
	    // you can set expectations and use mocks in fixture-context
	    (waterContainerMock.isEmpty _).expects().returning(true)

	    // and define helper functions
	    def complexLogic() {
	      coffeeMachine.powerOff()
	      // ...
	    }
	}

	it should "not turn on the heater when the water container is overfull" in new OverfullWaterContainerTest {
	    // ...
	    complexLogic()
	}
}

    See org.scalamock for overview documentation.

  7. trait PathMockFactory extends SuiteMixin with MockFactoryBase with Mock

    Trait that can be mixed into org.scalatest.path.* specs (e.g.

    Trait that can be mixed into org.scalatest.path.* specs (e.g. path.FunSpec).

    MockFactory cannot be used because it overrides a final method. If you use path.FunSpec you need to verify expectations yourself - just add verifyExpectations at the end of the root-level suite.

    See MockFactory for more information.

Inherited from AnyRef

Inherited from Any

Ungrouped