test
An Annotated[A] contains a value of type A along with zero or more test
annotations.
The Annotations trait provides access to an annotation map that tests can
add arbitrary annotations to.
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.
An Assertion[A] is capable of producing assertion results on an A.
An Assertion[A] is capable of producing assertion results on an A. As a
proposition, assertions compose using logical conjunction and disjunction,
and can be negated.
An AssertionM[A] is capable of producing assertion results on an A.
An AssertionM[A] is capable of producing assertion results on an A. As a
proposition, assertions compose using logical conjunction and disjunction,
and can be negated.
An AssertionValue keeps track of a assertion and a value, existentially
hiding the type.
An AssertionValue keeps track of a assertion and a value, existentially
hiding the type. This is used internally by the library to provide useful
error messages in the event of test failures.
A BoolAlgebra[A] is a description of logical operations on values of type
A.
CustomAssertion allows users to create their own custom assertions for use in
assertTrue.
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 default runnable spec that provides testable versions of all of the modules in ZIO (Clock, Random, etc).
A value of type Eql[A, B] provides implicit evidence that two values with
types A and B could potentially be equal, that is, that A is a subtype
of B or B is a subtype of A.
A value of type Eql[A, B] provides implicit evidence that two values with
types A and B could potentially be equal, that is, that A is a subtype
of B or B is a subtype of A.
An ExecutedSpec is a spec that has been run to produce test results.
FailureDetails keeps track of details relevant to failures.
A Gen[R, A] represents a generator of values of type A, which requires an
environment R.
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" environment from within the
test environment for effects such as printing test results to the console or
timing out tests where it is necessary to access the real environment.
The Live trait provides access to the "live" environment from within the
test environment for effects such as printing test results to the console or
timing out tests where it is necessary to access the real environment.
The easiest way to access the "live" environment is to use the live method
with an effect that would otherwise access the test environment.
import zio.Clock import zio.test._ val realTime = live(Clock.nanoTime)
The withLive method can be used to apply a transformation to an effect with
the live environment while ensuring that the effect itself still runs with
the test environment, for example to time out a test. Both of these methods
are re-exported in the environment package for easy availability.
A RunnableSpec has a main function and can be run by the JVM / Scala.js.
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, T] is the backbone of _ZIO Test_.
A Spec[R, E, T] is the backbone of _ZIO Test_. Every spec is either a
suite, which contains other specs, or a test of type T. 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.
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.
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.
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 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.
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.
TestRandom allows for deterministically testing effects involving
randomness.
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 TestReporter[E] is capable of reporting test results with error type
E.
A TestRunner[R, E] encapsulates all the logic necessary to run specs that
require an environment R and may fail with an error E.
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.
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")
A ZSpec[R, E] is the canonical spec for testing ZIO programs.
A ZSpec[R, E] is the canonical spec for testing ZIO programs. The spec's
test type is a ZIO effect that requires an R and might fail with an E.
A ZTest[R, E] is an effectfully produced test that requires an R and
may fail with an E.
A ZRTestEnv is an alias for all ZIO provided
Restorable
TestEnvironment objects
A ZTestLogger is an implementation of a ZLogger that writes all log
messages to an internal data structure.
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) }
Syntax for writing test like
Syntax for writing test like
object MySpec extends DefaultMutableRunnableSpec { suite("foo") { test("name") { } @@ ignore test("name 2") } suite("another suite") { test("name 3") } }
(Since version 2.0.0) use DefaultRunnableSpec
Syntax for writing test like
Syntax for writing test like
object MySpec extends MutableRunnableSpec(layer, aspect) { suite("foo") { test("name") { } @@ ignore test("name 2") } suite("another suite") { test("name 3") } }
(Since version 2.0.0) use RunnableSpec
Proxy methods to call package private methods from the macro
TestPlatform provides information about the platform tests are being run on
to enable platform specific test configuration.
TestVersion provides information about the Scala version tests are being
run on to enable platform specific test configuration.
Checks the assertion holds for the given value.
Checks the assertion holds for the given value.
Asserts that the given test was completed.
Asserts that the given test was completed.
Checks the assertion holds for the given effectfully-computed value.
Checks the assertion holds for the given effectfully-computed value.
Asserts that the given test was never completed.
Checks the assertion holds for the given value.
Checks the assertion holds for the given value.
A version of check that accepts six random variables.
A version of check that accepts five random variables.
A version of check that accepts four random variables.
A version of check that accepts three random variables.
A version of check that accepts two random variables.
Checks the test passes for "sufficient" numbers of samples from the given random variable.
A version of checkAll that accepts six random variables.
A version of checkAll that accepts five random variables.
A version of checkAll that accepts four random variables.
A version of checkAll that accepts three random variables.
A version of checkAll that accepts two random variables.
Checks the test passes for all values from the given random variable.
Checks the 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 checkAllMPar that accepts six random variables.
A version of checkAllMPar that accepts five random variables.
A version of checkAllMPar that accepts four random variables.
A version of checkAllMPar that accepts three random variables.
A version of checkAllMPar that accepts two random variables.
Checks in parallel the effectual test passes for all values from the given random variable.
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.
Checks the test passes for the specified number of samples from the given random variable.
A Runner that provides a default testable environment.
Creates a failed test result with the specified runtime cause.
Creates an ignored test result.
The laws package provides functionality for describing laws as values.
The laws package provides functionality for describing laws as values. The
fundamental abstraction is a set of ZLaws[Caps, R]. These laws model the
laws that instances having a capability of type Caps are expected to
satisfy. A capability Caps[_] is an abstraction describing some
functionality that is common across different data types and obeys certain
laws. For example, we can model the capability of two values of a type being
compared for equality as follows:
trait Equal[-A] { def equal(a1: A, a2: A): Boolean }
Definitions of equality are expected to obey certain laws:
a1 === a1a1 === a2 ==> a2 === a1(a1 === a2) && (a2 === a3) ==> (a1 === a3)These laws define what the capabilities mean and ensure that it is safe to abstract across different instances with the same capability.
Using ZIO Test, we can represent these laws as values. To do so, we define
each law using one of the ZLaws constructors. For example:
val transitivityLaw = ZLaws.Laws3[Equal]("transitivityLaw") { def apply[A: Equal](a1: A, a2: A, a3: A): TestResult = ??? }
We can then combine laws using the + operator:
val reflexivityLaw: = ??? val symmetryLaw: = ??? val equalLaws = reflexivityLaw + symmetryLaw + transitivityLaw
Laws have a run method that takes a generator of values of type A and
checks that those values satisfy the laws. In addition, objects can extend
ZLawful to provide an even more convenient syntax for users to check that
instances satisfy certain laws.
object Equal extends Lawful[Equal] object Hash extends Lawful[Hash] object Ord extends Lawful[Ord] checkAllLaws(Equal + Hash + Ord)(Gen.int)
Note that capabilities compose seamlessly because of contravariance. We can combine laws describing different capabilities to construct a set of laws requiring that instances having all of the capabilities satisfy each of the laws.
Provides an effect with the "real" environment as opposed to the test environment.
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.
Passes platform specific information to the specified function, which will use that information to create a test.
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.
Builds a suite containing a number of other specs.
Builds a spec with a single test.
Returns either Right if the specified string type checks as valid Scala
code or Left with an error message otherwise.
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.
Passes version specific information to the specified function, which will use that information to create a test.
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.
Transforms this effect with the specified function.
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))
A version of checkAllM that accepts six random variables.
A version of checkAllM that accepts six random variables.
(Since version 2.0.0) use checkAll
A version of checkAllM that accepts five random variables.
A version of checkAllM that accepts five random variables.
(Since version 2.0.0) use checkAll
A version of checkAllM that accepts four random variables.
A version of checkAllM that accepts four random variables.
(Since version 2.0.0) use checkAll
A version of checkAllM that accepts three random variables.
A version of checkAllM that accepts three random variables.
(Since version 2.0.0) use checkAll
A version of checkAllM that accepts two random variables.
A version of checkAllM that accepts two random variables.
(Since version 2.0.0) use checkAll
Checks the effectual test passes for all values from the given random variable.
Checks 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.
(Since version 2.0.0) use checkAll
A version of checkAllMPar that accepts six random variables.
A version of checkAllMPar that accepts six random variables.
(Since version 2.0.0) use checkPar
A version of checkAllMPar that accepts five random variables.
A version of checkAllMPar that accepts five random variables.
(Since version 2.0.0) use checkPar
A version of checkAllMPar that accepts four random variables.
A version of checkAllMPar that accepts four random variables.
(Since version 2.0.0) use checkPar
A version of checkAllMPar that accepts three random variables.
A version of checkAllMPar that accepts three random variables.
(Since version 2.0.0) use checkPar
A version of checkAllMPar that accepts two random variables.
A version of checkAllMPar that accepts two random variables.
(Since version 2.0.0) use checkPar
Checks in parallel the effectual test passes for all values from the given random variable.
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.
(Since version 2.0.0) use checkPar
A version of checkM that accepts six random variables.
A version of checkM that accepts six random variables.
(Since version 2.0.0) use check
A version of checkM that accepts five random variables.
A version of checkM that accepts five random variables.
(Since version 2.0.0) use check
A version of checkM that accepts four random variables.
A version of checkM that accepts four random variables.
(Since version 2.0.0) use check
A version of checkM that accepts three random variables.
A version of checkM that accepts three random variables.
(Since version 2.0.0) use check
A version of checkM that accepts two random variables.
A version of checkM that accepts two random variables.
(Since version 2.0.0) use check
Checks the effectual test passes for "sufficient" numbers of samples from the given random variable.
Checks the effectual test passes for "sufficient" numbers of samples from the given random variable.
(Since version 2.0.0) use check
Checks the effectual test passes for the specified number of samples from the given random variable.
Checks the effectual test passes for the specified number of samples from the given random variable.
(Since version 2.0.0) use checkN
Builds an effectual suite containing a number of other specs.
Builds an effectual suite containing a number of other specs.
(Since version 2.0.0) use suite
Builds a spec with a single effectful test.
Builds a spec with a single effectful test.
(Since version 2.0.0) use test
_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.