zio.test

The Annotations trait provides access to an annotation map that tests can add arbitrary annotations to. Each annotation consists of a string identifier, an initial value, and a function for combining two values. Annotations form monoids and you can think of Annotations as a more structured logging service or as a super polymorphic version of the writer monad effect.

Proxy methods to call package private methods from the macro

CustomAssertion allows users to create their own custom assertions for use in assertTrue. They are constructed with CustomAssertion.make.

// Definition
sealed trait Pet
case class Dog(hasBone: Boolean) extends Pet
case class Fish(bubbles: Double) extends Pet
case class Cat(livesRemaining: Int) extends Color

val lives =
 CustomAssertion.make[Pet] {
   case Cat(livesRemaining) => Right(livesRemaining)
   case other => Left(s"Expected $$other to be Cat")
 }

// Usage
suite("custom assertions")(
 test("as even") {
   val pet: Option[Pet] = Some(Cat(8))
   assertTrue(pet.is(_.some.custom(lives)) == 8)
 }
)

A Gen[R, A] represents a generator of values of type A, which requires an environment R. Generators may be random or deterministic.

GenFailureDetails keeps track of relevant information related to a failure in a generative test.

The Live trait provides access to the "live" default ZIO services from within ZIO Test for workflows such as printing test results to the console or timing out tests where it is necessary to access the real implementations of these services.

The easiest way to access the "live" services is to use the live method with a workflow that would otherwise use the test version of the default ZIO services.

import zio.Clock
import zio.test._

val realTime = live(Clock.nanoTime)

The withLive method can be used to apply a transformation to a workflow with the live services while ensuring that the workflow itself still runs with the test services, for example to time out a test. Both of these methods are re-exported in the ZIO Test package object for easy availability.

A sample is a single observation from a random variable, together with a tree of "shrinkings" used for minimization of "large" failures.

A Spec[R, E] is the backbone of ZIO Test. Every spec is either a suite, which contains other specs, or a test. All specs require an environment of type R and may potentially fail with an error of type E.

A type of annotation.

An annotation map keeps track of annotations of different types.

A TestAnnotationRenderer knows how to render test annotations.

A TestAspect is an aspect that can be weaved into specs. You can think of an aspect as a polymorphic function, capable of transforming one test into another, possibly enlarging the environment or error type.

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 clock time. Users can adjust the clock time using the adjust and setTime methods, and all effects scheduled to take place on or before that time will automatically be run in order.

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

 import zio.ZIO
 import zio.test.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 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 time on the line below. Thus, a useful pattern when using TestClock is to fork the effect being tested, then adjust the clock time, and finally verify that the expected effects have been performed.

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

 import zio.Queue
 import zio.test.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 clock by 60 minutes exactly one value is placed in the queue, and when we adjust the clock by another 60 minutes exactly one more value is placed in the queue.

The TestConfig service provides access to default configuration settings used by ZIO Test, including the number of times to repeat tests to ensure they are stable, the number of times to retry flaky tests, the sufficient number of samples to check from a random variable, and the maximum number of shrinkings to minimize large failures.

TestConsole provides a testable interface for programs interacting with the console by modeling input and output as reading from and writing to input and output buffers maintained by TestConsole and backed by a Ref.

All calls to print and printLine using the TestConsole will write the string to the output buffer and all calls to readLine will take a string from the input buffer. To facilitate debugging, by default output will also be rendered to standard output. You can enable or disable this for a scope using debug, silent, or the corresponding test aspects.

TestConsole has several methods to access and manipulate the content of these buffers including feedLines to feed strings to the input buffer that will then be returned by calls to readLine, output to get the content of the output buffer from calls to print and printLine, and clearInput and clearOutput to clear the respective buffers.

Together, these functions make it easy to test programs interacting with the console.

import zio.Console._
import zio.test.TestConsole
import zio.ZIO

val sayHello = for {
 name <- readLine
 _    <- printLine("Hello, " + name + "!")
} yield ()

for {
 _ <- TestConsole.feedLines("John", "Jane", "Sally")
 _ <- ZIO.collectAll(List.fill(3)(sayHello))
 result <- TestConsole.output
} yield result == Vector("Hello, John!\n", "Hello, Jane!\n", "Hello, Sally!\n")

A TestExecutor[R, E] is capable of executing specs that require an environment R and may fail with an E.

TestPlatform provides information about the platform tests are being run on to enable platform specific test configuration.

TestRandom allows for deterministically testing effects involving randomness.

TestRandom operates in two modes. In the first mode, TestRandom is a purely functional pseudo-random number generator. It will generate pseudo-random values just like scala.util.Random except that no internal state is mutated. Instead, methods like nextInt describe state transitions from one random state to another that are automatically composed together through methods like flatMap. The random seed can be set using setSeed and TestRandom is guaranteed to return the same sequence of values for any given seed. This is useful for deterministically generating a sequence of pseudo-random values and powers the property based testing functionality in ZIO Test.

In the second mode, TestRandom maintains an internal buffer of values that can be "fed" with methods such as feedInts and then when random values of that type are generated they will first be taken from the buffer. This is useful for verifying that functions produce the expected output for a given sequence of "random" inputs.

import zio.Random
import zio.test.TestRandom

for {
 _ <- TestRandom.feedInts(4, 5, 2)
 x <- Random.nextIntBounded(6)
 y <- Random.nextIntBounded(6)
 z <- Random.nextIntBounded(6)
} yield x + y + z == 11

TestRandom will automatically take values from the buffer if a value of the appropriate type is available and otherwise generate a pseudo-random value, so there is nothing you need to do to switch between the two modes. Just generate random values as you normally would to get pseudo-random values, or feed in values of your own to get those values back. You can also use methods like clearInts to clear the buffer of values of a given type so you can fill the buffer with new values or go back to pseudo-random number generation.

A TestRunner[R, E] encapsulates all the logic necessary to run specs that require an environment R and may fail with an error E. Test runners require a test executor, a runtime configuration, and a reporter.

TestSystem supports deterministic testing of effects involving system properties. Internally, TestSystem maintains mappings of environment variables and system properties that can be set and accessed. No actual environment variables or system properties will be accessed or set as a result of these actions.

import zio.system
import zio.test.TestSystem

for {
 _      <- TestSystem.putProperty("java.vm.name", "VM")
 result <- system.property("java.vm.name")
} yield result == Some("VM")

TestVersion provides information about the Scala version tests are being run on to enable platform specific test configuration.

A ZTestLogger is an implementation of a ZLogger that writes all log messages to an internal data structure. The contents of this data structure can be accessed using the logOutput operator. This makes it easy to write tests to verify that expected messages are being logged.

test("logging works") {
 for {
   _      <- ZIO.logDebug("It's alive!")
   output <- ZTestLogger.logOutput
 } yield assertTrue(output.length == 1) &&
   assertTrue(output(0).message() == "It's alive!") &&
   assertTrue(output(0).logLevel == LogLevel.Debug)
}

A TestAspectAtLeast[R] is a TestAspect that requires at least an R in its environment.

A TestAspectPoly is a TestAspect that is completely polymorphic, having no requirements on error or environment.

A ZTest[R, E] is an effectfully produced test that requires an R and may fail with an E.

Retrieves the Annotations service for this test.

Retrieves the Annotations service for this test and uses it to run the specified workflow.

Asserts that the given test was completed.

Asserts that the given test was completed.

Asserts that the given test was never completed.

Checks the test passes for "sufficient" numbers of samples from the given random variable.

A version of check that accepts two random variables.

A version of check that accepts three random variables.

A version of check that accepts four random variables.

A version of check that accepts five random variables.

A version of check that accepts six random variables.

A version of check that accepts seven random variables.

A version of check that accepts eight random variables.

Checks the test passes for all values from the given finite, deterministic generator. For non-deterministic or infinite generators use check or checkN.

A version of checkAll that accepts two random variables.

A version of checkAll that accepts three random variables.

A version of checkAll that accepts four random variables.

A version of checkAll that accepts five random variables.

A version of checkAll that accepts six random variables.

A version of checkAll that accepts seven random variables.

A version of checkAll that accepts eight random variables.

Checks in parallel the effectual test passes for all values from the given random variable. This is useful for deterministic Gen that comprehensively explore all possibilities in a given domain.

A version of checkAllPar that accepts two random variables.

A version of checkAllPar that accepts three random variables.

A version of checkAllPar that accepts four random variables.

A version of checkAllPar that accepts five random variables.

A version of checkAllPar that accepts six random variables.

A version of checkAllPar that accepts six random variables.

A version of checkAllPar that accepts six random variables.

Checks the test passes for the specified number of samples from the given random variable.

Creates a failed test result with the specified runtime cause.

Provides an effect with the "real" environment as opposed to the test environment. This is useful for performing effects such as timing out tests, accessing the real time, or printing to the real console.

Retrieves the Live service for this test.

Retrieves the Live service for this test and uses it to run the specified workflow.

Passes platform specific information to the specified function, which will use that information to create a test. If the platform is neither ScalaJS nor the JVM, an ignored test result will be returned.

Retrieves the Sized service for this test.

Retrieves the Sized service for this test and uses it to run the specified workflow.

Builds a suite containing a number of other specs.

Builds a spec with a single test.

Retrieves the TestClock service for this test.

Retrieves the TestClock service for this test and uses it to run the specified workflow.

Retrieves the TestConfig service for this test.

Retrieves the TestConfig service for this test and uses it to run the specified workflow.

Retrieves the TestConsole service for this test.

Retrieves the TestConsole service for this test and uses it to run the specified workflow.

Retrieves the TestRandom service for this test.

Retrieves the TestRandom service for this test and uses it to run the specified workflow.

Retrieves the TestSystem service for this test.

Retrieves the TestSystem service for this test and uses it to run the specified workflow.

Passes version specific information to the specified function, which will use that information to create a test. If the version is neither Scala 3 nor Scala 2, an ignored test result will be returned.

Executes the specified workflow with the specified implementation of the annotations service.

Sets the implementation of the annotations service to the specified value and restores it to its original value when the scope is closed.

Executes the specified workflow with the specified implementation of the live service.

Transforms this effect with the specified function. The test environment will be provided to this effect, but the live environment will be provided to the transformation function. This can be useful for applying transformations to an effect that require access to the "real" environment while ensuring that the effect itself uses the test environment.

 withLive(test)(_.timeout(duration))

Sets the implementation of the live service to the specified value and restores it to its original value when the scope is closed.

Executes the specified workflow with the specified implementation of the sized service.

Sets the implementation of the sized service to the specified value and restores it to its original value when the scope is closed.

Executes the specified workflow with the specified implementation of the config service.

Sets the implementation of the config service to the specified value and restores it to its original value when the scope is closed.

Returns either Right if the specified string type checks as valid Scala code or Left with an error message otherwise. Dies with a runtime exception if specified string cannot be parsed or is not a known value at compile time.

A Runner that provides a default testable environment.

Creates an ignored test result.