Executes the body of the constructor that was passed to delayedInit.
Executes the body of the constructor that was passed to delayedInit.
Saves the body of the constructor, passed as body, for later execution by apply.
Saves the body of the constructor, passed as body, for later execution by apply.
This method exists to cause a compile-time type error if someone accidentally
tries to mix this trait into a Suite.
This method exists to cause a compile-time type error if someone accidentally
tries to mix this trait into a Suite.
This trait is intended to be mixed
into classes that are constructed within the body (or as the body) of tests, not mixed into Suites themselves. For an example,
the the main Scaladoc comment for this trait.
A function that takes no parameters (i.e., a
Function0or "no-arg" function) and results inUnit, which when invoked executes the body of the constructor of the class into which this trait is mixed.This trait extends
DelayedInitand defines adelayedInitmethod that saves the body of the constructor (passed todelayedInit) for later execution whenapplyis invoked.This trait is somewhat magical and therefore may be challenging for your collegues to understand, so please use it as a last resort only when the simpler options described in the "shared fixtures" section of your chosen style trait won't do the job.
NoArgis intended to address a specific use case that will likely be rare, and is unlikely to be useful outside of its intended use case, but it is quite handy for its intended use case (described in the next paragraph). One potential gotcha, for example, is that a subclass's constructor body could in theory be executed multiple times by simply invokingapplymultiple times. In the intended use case for this trait, however, the body will be executed only once. In addition, theNoArgmethod is not thread safe, as it is intended to be used by just one thread, which is executing a test.The intended use case for this method is (relatively rare) situations in which you want to extend a different instance of the same class for each test, with the body of the test inheriting the members of that class, and with code executed before and/or after the body of the test.
For example, Akka's
TestKitclass takes anActorSystem, which must have a unique name. To run a suite of tests in parallel, each test must get its ownActorSystem, to ensure the tests run in isolation. At the end of each test, theActorSystemmust be shutdown. WithNoArg, you can achieve this by first defining a class that extendsTestKitand mixes inNoArg. Here's an example taken with permission from the book Akka Concurrency, by Derek Wyatt:Given this implementation of
ActorSys, which will invokeshutdownafter the constructor code is executed, you can run each test in a suite in a subclass ofTestKit, giving each test'sTestKitanActorSystemwith a unique name, allowing you to safely run those tests in parallel. Here's an example from Akka Concurrency:UnitFixtureis used in this example, because in this case, thefixture.WordSpecfeature enabling tests to be defined as functions from fixture objects of typeFixtureParamtoUnitis not being used. Rather, only the secondary feature that enables tests to be defined as functions from no parameters toUnitis being used. This secondary feature is described in the second-to-last paragraph on the main Scaladoc documentation offixture.WordSpec, which says:Since
FixtureParamis unused in this use case, it could be anything. Making itUnitwill hopefully help readers more easily recognize that it is not being used.