Packages

  • package root
    Definition Classes
    root
  • package zio
    Definition Classes
    root
  • package test

    _ZIO Test_ is a featherweight testing library for effectful programs.

    _ZIO Test_ is a featherweight testing library for effectful programs.

    The library imagines every spec as an ordinary immutable value, providing tremendous potential for composition. Thanks to tight integration with ZIO, specs can use resources (including those requiring disposal), have well- defined linear and parallel semantics, and can benefit from a host of ZIO combinators.

    import zio.test._
import zio.clock.nanoTime
import Assertion.isGreaterThan

object MyTest extends DefaultRunnableSpec {
  def spec = suite("clock")(
    testM("time is non-zero") {
      assertM(nanoTime)(isGreaterThan(0))
    }
  )
}
    Definition Classes
    zio
  • package diff
    Definition Classes
    test
  • package environment

    The environment package contains testable versions of all the standard ZIO environment types through the TestClock, TestConsole, TestSystem, and TestRandom modules.

    The environment package contains testable versions of all the standard ZIO environment types through the TestClock, TestConsole, TestSystem, and TestRandom modules. See the documentation on the individual modules for more detail about using each of them.

    If you are using ZIO Test and extending RunnableSpec a TestEnvironment containing all of them will be automatically provided to each of your tests. Otherwise, the easiest way to use the test implementations in ZIO Test is by providing the TestEnvironment to your program.

    import zio.test.environment._

myProgram.provideLayer(testEnvironment)

    Then all environmental effects, such as printing to the console or generating random numbers, will be implemented by the TestEnvironment and will be fully testable. When you do need to access the "live" environment, for example to print debugging information to the console, just use the live combinator along with the effect as your normally would.

    If you are only interested in one of the test implementations for your application, you can also access them a la carte through the make method on each module. Each test module requires some data on initialization. Default data is included for each as DefaultData.

    import zio.test.environment._

myProgram.provideM(TestConsole.make(TestConsole.DefaultData))

    Finally, you can create a Test object that implements the test interface directly using the makeTest method. This can be useful when you want to access some testing functionality without using the environment type.

    import zio.test.environment._

for {
  testRandom <- TestRandom.makeTest(TestRandom.DefaultData)
  n          <- testRandom.nextInt
} yield n

    This can also be useful when you are creating a more complex environment to provide the implementation for test services that you mix in.

    Definition Classes
    test
  • package mock
    Definition Classes
    test
  • ArgumentExpectation
  • Expectation
  • Invocation
  • Method
  • Mock
  • MockClock
  • MockConsole
  • MockException
  • MockRandom
  • MockSystem
  • Mockable
  • ReturnExpectation
  • Spyable
  • package poly
    Definition Classes
    test
  • package reflect
    Definition Classes
    test
p

zio.test

mock

package mock

Ordering
  1. Alphabetic
Visibility
  1. Public
  2. All

Type Members

  1. final case class ArgumentExpectation[-M, I, A](method: Method[M, I, A], assertion: Assertion[I]) extends Product with Serializable

    An ArgumentExpectation[M, I, A] represents an expectation on input I arguments for capability of module M that returns an effect that may produce a single A.

  2. sealed trait Expectation[-M, +E, +A] extends AnyRef

    An Expectation[-M, +E, +A] is an immutable data structure that represents expectations on module M capabilities.

    An Expectation[-M, +E, +A] is an immutable data structure that represents expectations on module M capabilities.

    This structure is a monad, because we need the sequential composability and in Scala we get the convenient for-comprehension syntax for free.

    • Empty models expectation for no calls, the monadic unit value
    • Call models a call on M modules capability that takes arguments I and returns an effect that may fail with an error E or produce a single A
    • FlatMap models sequential composition of expectations

    The whole structure is not supposed to be consumed directly by the end user, instead it should be converted into a mocked environment (wrapped in layer) either explicitly via toLayer method or via implicit conversion.

  3. final case class Invocation[-M, I, A](method: Method[M, I, A], input: I, output: A) extends Product with Serializable

    An Invocation[M, I, A] models a single invocation of a Method[M, I, A], including both the input to the method invocation I and the output from the method invocation A.

  4. trait Method[-M, I, A] extends AnyRef

    A Model[M, I, A] represents a capability of module M that takes an input I and returns an effect that may produce a single A.

  5. trait Mock extends AnyRef
  6. sealed trait MockException extends Throwable

    A MockException is used internally by the mock framework to signal failed expectations to the test framework.

  7. trait Mockable[A] extends AnyRef

    The Mockable[A] represents a mock service builder used by the mock framework to construct a mock implementation from a mock.

  8. sealed trait ReturnExpectation[-I, +E, +A] extends AnyRef

    A ReturnExpectation[-I, E, +A] represents an expectation on output for capability of module M that given input arguments I returns an effect that may fail with an error E or produce a single A.

  9. trait Spyable[A] extends Mockable[A]

    Spyable[A] models the capability to spy on a service of type A.

    Spyable[A] models the capability to spy on a service of type A. Implementations must define both a method environment to genereate a live environment given a mock and a method mock to generate a mock given a live environment. Given these definitions, it is possible to convert a service to a mock, see and modify state based on method calls, inputs, and outputs, and then convert the mock back to a live environment to spy on the service.

Value Members

  1. object Expectation
  2. object Mock
  3. object MockClock
  4. object MockConsole
  5. object MockException extends Serializable
  6. object MockRandom
  7. object MockSystem
  8. object ReturnExpectation
  9. object Spyable

Ungrouped