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 {
      suite("clock") {
        testM("time is non-zero") {
          assertM(nanoTime, isGreaterThan(0))
        }
      }
    }
    Definition Classes
    zio
  • 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 DefaultRunnableSpec 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.provideManaged(testEnvironmentManaged)

    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
  • Method
  • Mock
  • MockClock
  • MockConsole
  • MockException
  • MockRandom
  • MockSystem
  • Mockable
  • ReturnExpectation
  • package reflect
    Definition Classes
    test

package mock

Ordering
  1. Alphabetic
Visibility
  1. Public
  2. Protected

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 Managed) either explicitly via managedEnv method or via implicit conversion.

  3. 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.

  4. trait Mock extends AnyRef
  5. trait MockClock extends Clock
  6. trait MockConsole extends Console
  7. sealed trait MockException extends Throwable

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

  8. trait MockRandom extends Random
  9. trait MockSystem extends System
  10. 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.

  11. 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.

Value Members

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

Ungrouped