Is it possible to access the name of the currently executing test, from within a ScalaTest test? (And how would I do it?)
Background:
I'm testing that my Data Access Object eventually throws an OverQuotaException if a user e.g. creates too many pages. These tests take rather long to run. To feel happier, I'd like to print the progress to stdout — and since there are quite many tests, I'd like to include the test name in the output, so I know what test is currently being run.
(I didn't find any seemingly relevant function here: http://www.artima.com/docs-scalatest-2.0.M5/#org.scalatest.FreeSpec )
Example:
"QuotaCharger can" - {
"charge and decline quota consumers" - {
"charge a per site IP number (guest user)" in {
// ... Here, a guest user post very many comments until it's over quota.
// This takes a little while, and there are many similar tests.
// ---> Here <--- I'd like to access the string:
// "charge a per site IP number (guest user)",
// is that possible somehow?
}
The intended way to do that is to override withFixture and capture the test data. In this use case, it is better to override withFixture in fixture.FreeSpec so you can pass the test data into each test rather than using a var. Info on that is here:
http://www.artima.com/docs-scalatest-2.0.M5/org/scalatest/FreeSpec.html#withFixtureNoArgTest
When I saw your question this morning I realized ScalaTest should have a trait that does this, so I just added one. It will be in 2.0.M6, the next milestone release, but in the meantime you can use a local copy. Here it is:
import org.scalatest._
/**
* Trait that when mixed into a <code>fixture.Suite</code> passes the
* <code>TestData</code> passed to <code>withFixture</code> as a fixture into each test.
*
* #author Bill Venners
*/
trait TestDataFixture { this: fixture.Suite =>
/**
* The type of the fixture, which is <code>TestData</code>.
*/
type FixtureParam = TestData
/**
* Invoke the test function, passing to the the test function to itself, because
* in addition to being the test function, it is the <code>TestData</code> for the test.
*
* <p>
* To enable stacking of traits that define <code>withFixture(NoArgTest)</code>, this method does not
* invoke the test function directly. Instead, it delegates responsibility for invoking the test function
* to <code>withFixture(NoArgTest)</code>.
* </p>
*
* #param test the <code>OneArgTest</code> to invoke, passing in the
* <code>TestData</code> fixture
*/
def withFixture(test: OneArgTest) {
withFixture(test.toNoArgTest(test))
}
}
You would use it like this:
import org.scalatest._
class MySpec extends fixture.FreeSpec with TestDataFixture {
"this technique" - {
"should work" in { td =>
assert(td.name == "this technique should work")
}
"should be easy" in { td =>
assert(td.name == "this technique should be easy")
}
}
}
Create your own trait, let say RichFreeSpec.
trait RichFreeSpec extends Free {
protected final class RichFreeSpecStringWrapper(name: scala.Predef.String) {
def in(f: String => scala.Unit) {
def f2 = f(name)
new WordSpecStringWrapper(string).in(f2)
}
}
protected implicit def convertToRichFreeSpecStringWrapper(n: scala.Predef.String): = {
new RichFreeSpecStringWrapper(n)
}
}
Than just use:
"sth" in { testName =>
...
}
Of course, you can go further and implement the full name hierarchy.
You can use BeforeAndAfterEachTestData for what you need.
If you need access to the test case name in the beforeEach or afterEach method.
class MyTestSuite with AnyFunSuiteLike with BeforeAndAfterEachTestData {
override def beforeEach(testData: TestData): Unit = {
testData.name // do whatever.
super.beforeEach(testData)
}
}
If you need access to the test case name in the test case itself, then you can use a thread local approach
private val currentTestCaseName = new ThreadLocal[String]
override def beforeEach(testData: TestData): Unit = {
currentTestCaseName.set(testData.name)
super.beforeEach(testData)
}
test("fancy test") {
currentTestCaseName.get() // do whatever
}
Here's a solution. Extend this class instead of FreeSpec. License: CC0.
Edit: This doesn't work with concurrent tests though.
(The difference between this approach and the other answer, is that 1) here there's a currentTestName field, and in the other answer the test name is passed to the test body, and 2) this test name includes all test branch names concatenated + the actual test name, whereas the other answer's test name is exactly the test name (without test branch names).)
(Ooops, you'd need to use getOrElse ... instead of my lovely getOrDie.)
/**
* Adds a field `currentTestName` that you can use inside a FreeSpec test,
* if you for example have many tests that take rather long, and you wonder
* which one is currently running.
*/
trait RichFreeSpec extends FreeSpec {
private var _currentTestName: Option[String] = None
def currentTestName = _currentTestName getOrDie "DwE90RXP2"
protected override def runTest(testName: String, args: org.scalatest.Args) {
_currentTestName = Some(testName)
super.runTest(testName, args)
}
}
If the intent is to be able to access the test name from anywhere, as was suggested by #kajmanus in previous comments, a ThreadLocal fits the bill nicely.
You could define a case class to store the info you require for the current test context. e.g.,
case class TestContext(name: Option[String] = None)
object TestContext {
val currentTest: ThreadLocal[TestContext] =
ThreadLocal.withInitial(() => TestContext())
}
Then define a trait your various specs will extend. e.g.,
trait BaseFunSpec
extends AnyFunSpec
...
{
override protected def withFixture(test: NoArgTest): Outcome = {
try {
TestContext.currentTest.set(TestContext(name = Some(test.name)))
super.withFixture(test)
} finally {
TestContext.currentTest.remove()
}
}
}
Finally, you can access the current test context you've set for the current thread (which in this example is purely the test name) from anywhere within the current thread as needed. e.g.,
def cachedResults(bytes: Array[Byte], fileType: String): Unit = {
TestContext.currentTest.get().name match {
case Some(testname) =>
import scala.util.Using
val file = new File("target", s"${testname}.${fileType}")
Using(new BufferedOutputStream(new FileOutputStream(file))) { os =>
os.write(bytes)
}
case None => throw new IllegalStateException("Unknown test context")
}
}
This will work whether you're running tests in parallel or not, assuming you're not processing things asynchronously (i.e., in another thread).
A cleaner usage of this is to create purposed actors. e.g.,
case class TestContext(name: Option[String] = None)
object TestContext {
val currentTest: ThreadLocal[TestContext] = ThreadLocal.withInitial(() => TestContext())
class TestNamer {
def currentName: String = currentTest.get().name match {
case Some(testname) => testname
case None => throw new IllegalStateException("No test context available")
}
}
class TestContextWriter(testNamer: TestNamer = new TestNamer()) {
def cachedBytes(bytes: Array[Byte], extension: String): Array[Byte] = {
import java.io.{BufferedOutputStream, File, FileOutputStream}
import scala.util.Using
val file = new File("target", s"${testNamer.currentName}.${extension}")
Using(new BufferedOutputStream(new FileOutputStream(file))) { outstream =>
outstream.write(bytes)
}
bytes
}
}
}
And inject as needed:
trait BaseFunSpec {
val testContextWriter = new TestContextWriter()
def fetchRawResults(...): Array[Byte] = {
...
testContextWriter.cachedBytes(bytes, "pdf")
}
}
Related
I have a HelperMethod class.
class HelperMethods {
def getUniqueID(): UUID = {
UUID.randomUUID()
}
def bucketIDFromEmail(email:String): Int = {
val bucketID= email(0).toInt
println("returning id "+bucketID+" for name "+email)
bucketID
}
}
And an object which has an instance of HelperMethods
package object utilities{
private val helper = new HelperMethods()
def getUniqueID(): UUID = helper.getUniqueID()
def bucketIDFromEmail(email:String): Int = helper.bucketIDFromEmail(email)
}
I wrote a spec to test that my mock works correctly.
class UserControllerUnitSpec extends PlaySpec {
val mockHelperMethods = mock(classOf[HelperMethods])
when(mockHelperMethods.getUniqueID()).thenReturn(UUID.fromString("87ea52b7-0a70-438f-81ff-b69ab9e57210"))
when(mockHelperMethods.bucketIDFromEmail(ArgumentMatchers.any[String])).thenReturn(1)
"mocking helper class " should {
"work" in {
val bucketId = utilities.bucketIDFromEmail("t#t.com")
println("user keys are " + userKeys)
val id: UUID = utilities.getUniqueID()
println("got id " + userKeys)
bucketId mustBe 1
id mustBe UUID.fromString("87ea52b7-0a70-438f-81ff-b69ab9e57210")
}
}
}
the test fails with reason 116 was not equal to 1. This corresponds to line
bucketId mustBe 1 in the spec. I can see the print returning id 116 for name t#t.com. I shouldn't see it as I am trying to mock this class. I suspect that it could be because the utilities object is getting created before the statement val mockHelperMethods = mock(classOf[HelperMethods]) in the spec.
Question 2- Is there a way to mock HelperMethods and make utilities use the mocked class?
You have mocked HelperMethods but not utilities.
Question 2- Is there a way to mock HelperMethods and make utilities use the mocked class?
It is not possible to mock an object.
If you want, you have to extract the behavior in a trait.
Here is a solution that would work:
package utils
// move the behavior to a trait:
trait UtitilitiesTrait {
private[utils] def helper = new HelperMethods()
def getUniqueID(): UUID = helper.getUniqueID()
def bucketIDFromEmail(email: String): Int = helper.bucketIDFromEmail(email)
}
// provide an object for real use
object Utilities extends UtitilitiesTrait
// override helper for test mock
object TestUtilities extends UtitilitiesTrait {
private[utils] override def helper = mock(classOf[HelperMethods])
}
And here is your test:
class UserControllerUnitSpec extends PlaySpec {
val mockHelperMethods = mock(classOf[HelperMethods])
object TestUtilities extends UtitilitiesTrait {
private[utils] override def helper = mockHelperMethods
}
when(mockHelperMethods.getUniqueID()).thenReturn(UUID.fromString("87ea52b7-0a70-438f-81ff-b69ab9e57210"))
when(mockHelperMethods.bucketIDFromEmail(ArgumentMatchers.any[String])).thenReturn(1)
"mocking helper class " should {
"work" in {
val bucketId = TestUtilities.bucketIDFromEmail("t#t.com")
println("user keys are " + userKeys)
val id: UUID = TestUtilities.getUniqueID()
println("got id " + userKeys)
bucketId mustBe 1
id mustBe UUID.fromString("87ea52b7-0a70-438f-81ff-b69ab9e57210")
}
}
}
The typical pattern that enables mocking objects used internally is to inject them, or at least provide a way to inject an alternate.
Since Utilities is an object, you can't inject using a constructor. You could still introduce a setter method.
If you'd like to discourage use of the setter for anything other than unit tests, make it package-private, and you might also prefix the name with "qa":
private[utils] def qaSetHelperMethods(qaHelper: HelperMethods): Unit
First off, I saw it and this other post sounds exactly like what I need except for one thing, I can't use fixture.TestDataFixture because I can't extend fixture.FreeSpecLike, and I am sure that there must be some way to get the test name in a way that looks more like this (imagined code that doesn't compile)
class MySpec extends FlatSpecLike with fixture.TestDataFixture {
"this technique" - {
"should work" in {
assert(testData.name == "this technique should work")
}
"should be easy" in { td =>
assert(testData.name == "this technique should be easy")
}
}
}
Any ideas? I just can't believe something like this is not possible :D
While you already came to basically this solution, here is a safer variation:
private val _currentTestName = new ThreadLocal[String]
override def withFixture(test: NoArgTest) = {
_currentTestName.set(test.name)
val outcome = super.withFixture(test)
_currentTestName.set(null)
outcome
}
protected def currentTestName: String = {
val testName = _currentTestName.get()
assert(testName != null, "currentTestName should only be called in a test")
testName
}
Alternately,
protected def currentTestName = Option(_currentTestName.get())
You can find sequence of test names using method testNames in FlatSpecLike trait:
import org.scalatest.FlatSpecLike
class FooSpec extends FlatSpecLike {
it should "check case one" in {
println("test some code ...")
println(testNames.mkString("\n"))
/*
prints:
should check case one
should check case two
*/
// ...
assert(1 == 1)
println("end.")
}
it should "check case two" in {
println("test some code ...")
assert(1 == 1)
println("end.")
}
}
and find each you needed. Hope it helps.
And found an answer(well a collegue did), not sure I like it but works:
on the trait that other tests depend on
class MySpec extends FlatSpecLike {
//... other stuff
var testName = "UndefinedTestName"
override def withFixture (test: NoArgTest) :Outcome= {
testName = test.name
super.withFixture(test)
}
}
simple solution but rather obscure, also I wonder if anyone sees any problems with it
Say, I'm using some json libraries which provides an object Json:
object Json {
def unapply[T](jsonStr:String)(implicit converter:Converter[T]) { ... }
}
I can use it in my scala code like this:
class MyLoginController {
def login(request:Request) = {
val loginInfo = Json.unapply[LoginInfo](request.body)
// check(loginInfo.email)
// check(loginInfo.password)
}
}
It's works perfectly, but soon I found my self can't test it easily with mock. I can't find a way to mock the Json.unapply.
So I have to change my code to provide a trait and use dependency injection:
trait JsonParsable[T] {
def parse(jsonStr:String)(implicit converter:Converter[T])
}
object JsonParser extends JsonParsable[T] {
def parse(jsonStr:String)(implicit converter:Converter[T]) = Json.unapply(jsonStr)
}
class MyLoginController(jsonParser:JsonParsable[T]) {
def login(request:Request) = {
val loginInfo = jsonParser.parse[LoginInfo](request.body)
// check(loginInfo.email)
// check(loginInfo.password)
}
}
And when I write unit test, I will mock a JsonParsable for the MyLoginController:
val fakeParser = mock[JsonParsable]
// ...
val controller = new MyLoginController(fakeParser)
// ...
My question is, do I have to do this to avoid using objects, just in order to make it testable?
I found previous code is simple and easy, but the later one is more complex :(
My current application is based on akka 1.1. It has multiple ProjectAnalysisActors each responsible for handling analysis tasks for a specific project. The analysis is started when such an actor receives a generic start message. After finishing one step it sends itself a message with the next step as long one is defined. The executing code basically looks as follows
sealed trait AnalysisEvent {
def run(project: Project): Future[Any]
def nextStep: AnalysisEvent = null
}
case class StartAnalysis() extends AnalysisEvent {
override def run ...
override def nextStep: AnalysisEvent = new FirstStep
}
case class FirstStep() extends AnalysisEvent {
override def run ...
override def nextStep: AnalysisEvent = new SecondStep
}
case class SecondStep() extends AnalysisEvent {
...
}
class ProjectAnalysisActor(project: Project) extends Actor {
def receive = {
case event: AnalysisEvent =>
val future = event.run(project)
future.onComplete { f =>
self ! event.nextStep
}
}
}
I have some difficulties how to implement my code for the run-methods for each analysis step. At the moment I create a new future within each run-method. Inside this future I send all follow-up messages into the different subsystems. Some of them are non-blocking fire-and-forget messages, but some of them return a result which should be stored before the next analysis step is started.
At the moment a typical run-method looks as follows
def run(project: Project): Future[Any] = {
Future {
progressActor ! typicalFireAndForget(project.name)
val calcResult = (calcActor1 !! doCalcMessage(project)).getOrElse(...)
val p: Project = ... // created updated project using calcResult
val result = (storage !! updateProjectInformation(p)).getOrElse(...)
result
}
}
Since those blocking messages should be avoided, I'm wondering if this is the right way. Does it make sense to use them in this use case or should I still avoid it? If so, what would be a proper solution?
Apparently the only purpose of the ProjectAnalysisActor is to chain future calls. Second, the runs methods seems also to wait on results to continue computations.
So I think you can try refactoring your code to use Future Composition, as explained here: http://akka.io/docs/akka/1.1/scala/futures.html
def run(project: Project): Future[Any] = {
progressActor ! typicalFireAndForget(project.name)
for(
calcResult <- calcActor1 !!! doCalcMessage(project);
p = ... // created updated project using calcResult
result <- storage !!! updateProjectInformation(p)
) yield (
result
)
}
I have the following scala code:
package dummy
import javax.servlet.http.{HttpServlet,
HttpServletRequest => HSReq, HttpServletResponse => HSResp}
import scala.actors.Actor
class DummyServlet extends HttpServlet {
RNG.start
override def doGet(req: HSReq, resp: HSResp) = {
def message = <HTML><HEAD><TITLE>RandomNumber </TITLE></HEAD><BODY>
Random number = {getRandom}</BODY></HTML>
resp.getWriter().print(message)
def getRandom: String = {var d = new DummyActor;d.start;d.getRandom}
}
class DummyActor extends Actor {
var result = "0"
def act = { RNG ! GetRandom
react { case (r:Int) => result = r.toString }
}
def getRandom:String = {
Thread.sleep(300)
result
}
}
}
// below code is not modifiable. I am using it as a library
case object GetRandom
object RNG extends Actor {
def act{loop{react{case GetRandom=>sender!scala.util.Random.nextInt}}}
}
In the above code, I have to use thread.sleep to ensure that there is enough time for result to get updated, otherwise 0 is returned. What is a more elegant way of doing this without using thread.sleep? I think I have to use futures but I cannot get my head around the concept. I need to ensure that each HTTP reaquest gets a unique random number (of course, the random number is just to explain the problem). Some hints or references would be appreciated.
Either use:
!! <-- Returns a Future that you can wait for
or
!? <-- Use the one with a timeout, the totally synchronous is dangerous
Given your definition of RNG, heres some REPL code to verify:
scala> def foo = { println(RNG.!?(1000,GetRandom)) }
foo: Unit
scala> foo
Some(-1025916420)
scala> foo
Some(-1689041124)
scala> foo
Some(-1633665186)
Docs are here: http://www.scala-lang.org/api/current/scala/actors/Actor.html