test
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 conjuction 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.
A default runnable spec that provides testable versions of all of the modules in ZIO (Clock, Random, etc).
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.
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, L, T] is the backbone of _ZIO Test_.
A Spec[R, E, L, 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 are
annotated with labels of type L, 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 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, error, or success type.
A TestAspectPoly is a TestAspect that is completely polymorphic,
having no requirements on error or environment.
A TestExecutor[R, L, T, E, S] is capable of executing specs containing
tests of type T, annotated with labels of type L, that require an
environment R and may fail with an E or succeed with a S.
A TestReporter[L, E, S] is capable of reporting test results annotated
with labels L, error type E, and success type S.
A TestRunner[R, E, L, S] encapsulates all the logic necessary to run specs
that require an environment R and may fail with an error E or succeed
with an S, using labels of type L.
A TestRunner[R, E, L, S] encapsulates all the logic necessary to run specs
that require an environment R and may fail with an error E or succeed
with an S, using labels of type L. Test runners require a test executor,
a platform, and a reporter.
A ZSpec[R, E, L, S] is the canonical spec for testing ZIO programs.
A ZSpec[R, E, L, S] is the canonical spec for testing ZIO programs. The
spec's test type is a ZIO effect that requires an R, might fail with an
E, might succeed with an S, and whose nodes are annotated with labels
L.
A ZTest[R, E, S] is an effectfully produced test that requires an R
and may fail with an E or succeed with a S.
A Runner that provides a default testable environment.
TestPlatform provides information about the platform tests are being run
on to enable platform specific test configuration.
Checks the assertion holds for the given value.
Asserts that the given test was completed.
Checks the assertion holds for the given effectfully-computed value.
A version of check that accepts four 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 three random variables.
A version of check that accepts two 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.
Checks the test passes for "sufficient" numbers of samples from the given random variable.
A version of checkAll that accepts four 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 three random variables.
A version of checkAll that accepts two 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 checkAllM that accepts four random variables.
A version of checkAllM that accepts four random variables.
A version of checkAllM that accepts three random variables.
A version of checkAllM that accepts three random variables.
A version of checkAllM that accepts two random variables.
A version of checkAllM that accepts two random variables.
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.
A version of checkM that accepts four random variables.
A version of checkM that accepts four random variables.
A version of checkM that accepts three random variables.
A version of checkM that accepts three random variables.
A version of checkM that accepts two random variables.
A version of checkM that accepts two random variables.
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.
A version of checkSome that accepts four random variables.
A version of checkSome that accepts four random variables.
A version of checkSome that accepts three random variables.
A version of checkSome that accepts three random variables.
A version of checkSome that accepts two random variables.
A version of checkSome that accepts two random variables.
Checks the test passes for the specified number of samples from the given random variable.
Checks the test passes for the specified number of samples from the given random variable.
A version of checkSomeM that accepts four random variables.
A version of checkSomeM that accepts four random variables.
A version of checkSomeM that accepts three random variables.
A version of checkSomeM that accepts three random variables.
A version of checkSomeM that accepts two random variables.
A version of checkSomeM that accepts two random variables.
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.
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.
Creates a failed test result with the specified runtime cause.
Creates an ignored test result.
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 pure test.
Builds a spec with a single effectful 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.