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

•  object TestClock extends Serializable

  TestClock makes it easy to deterministically and efficiently test effects involving the passage of time.

  TestClock makes it easy to deterministically and efficiently test effects involving the passage of time.

  Instead of waiting for actual time to pass, sleep and methods implemented in terms of it schedule effects to take place at a given wall clock time. Users can adjust the wall clock time using the adjust and setTime methods, and all effects scheduled to take place on or before that wall clock time will automically be run.

  For example, here is how we can test ZIO#timeout using TestClock:

  import zio.ZIO
  import zio.duration._
  import zio.test.environment.TestClock
  
  for {
    fiber  <- ZIO.sleep(5.minutes).timeout(1.minute).fork
    _      <- TestClock.adjust(1.minute)
    result <- fiber.join
  } yield result == None

  Note how we forked the fiber that sleep was invoked on. Calls to sleep and methods derived from it will semantically block until the wall clock time is set to on or after the time they are scheduled to run. If we didn't fork the fiber on which we called sleep we would never get to set the the wall clock time on the line below. Thus, a useful pattern when using TestClock is to fork the effect being tested, then adjust the wall clock time, and finally verify that the expected effects have been performed.

  Sleep and related combinators schedule events to occur at a specified duration in the future relative to the current fiber time (e.g. 10 seconds from the current fiber time). The fiber time is backed by a FiberRef and is incremented for the duration each fiber is sleeping. Child fibers inherit the fiber time of their parent so methods that rely on repeated sleep calls work as you would expect.

  For example, here is how we can test an effect that recurs with a fixed delay:

  import zio.Queue
  import zio.duration._
  import zio.test.environment.TestClock
  
  for {
    q <- Queue.unbounded[Unit]
    _ <- (q.offer(()).delay(60.minutes)).forever.fork
    a <- q.poll.map(_.isEmpty)
    _ <- TestClock.adjust(60.minutes)
    b <- q.take.as(true)
    c <- q.poll.map(_.isEmpty)
    _ <- TestClock.adjust(60.minutes)
    d <- q.take.as(true)
    e <- q.poll.map(_.isEmpty)
  } yield a && b && c && d && e

  Here we verify that no effect is performed before the recurrence period, that an effect is performed after the recurrence period, and that the effect is performed exactly once. The key thing to note here is that after each recurrence the next recurrence is scheduled to occur at the appropriate time in the future, so when we adjust the wall clock time by 60 minutes exactly one value is placed in the queue, and when we adjust the wall clock time by another 60 minutes exactly one more value is placed in the queue.

  Definition Classes

  environment

• Data
• FiberData
• Service
• Test
• WarningData

zio.test.environment.TestClock

Test