zio.test.environment
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.
Type members
Classlikes
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.environment._
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.
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.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 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.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 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.
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 putStr
and putStrLn
using the TestConsole
will write the
string to the output buffer and all calls to getStrLn
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 getStrLn
, output
to get the
content of the output buffer from calls to putStr
and putStrLn
, 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.environment.TestConsole
import zio.ZIO
val sayHello = for {
name <- getStrLn
_ <- putStrLn("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")
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.environment.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.
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.
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.environment.TestSystem
for {
_ <- TestSystem.putProperty("java.vm.name", "VM")
result <- system.property("java.vm.name")
} yield result == Some("VM")
Inherited classlikes
Types
Inherited types
- Inherited from:
- PlatformSpecific
Value members
Concrete methods
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.
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.
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.
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))