I am learning how to do unit tests with scalatest , but I have some basic questions as I am learning Scala/Scalatest
I wrote one scala script which has one scala object with several methods. My question is as follows: Should I write one unit test for the whole Scala object or should I write a test per function.
For example I wrote the following function :
Do you know how to write a test with scala test for this specific function:
def dataProcessing (input: List[String]) = {
val Data = input.map(_.trim).filter(x => !(x contains "$")).filter(line => Seq("11", "18").exists(s => line.contains(s))).map(elt => elt.replaceAll("""[\t\p{Zs}\.\$]+""", " ")).map(_.split("\\s+")).map(x => (x(1),x(1),x(3),dataLength(x(3)),dataType(x(3))))
return Data
}
Finally I am trying to use the test driven design best practices but still don't know how to proceed to write tests before writing code , Any tips how to proceed to be compliant with these practices.
Many thanks
In general, when you define a class or object, you should write tests for the methods someone using that class should call, and the other methods should be private. If you find yourself wanting to make methods public, just so they can be tested, consider moving them to a separate class or object.
There are a lot of testing styles supported by scala test. Personally, I like WordSpec. A basic test in progress would look like this:
class MyTest extends WordSpec with Matchers {
"My Object" should {
"process descriptors" when {
"there is one input" in {
val input = List("2010 Ford Mustang")
val output = MyObject.descriptorProcessing(input)
output should have length 1
output.head shouldBe()
}
"there are two inputs" in pendingUntilFixed {
val input = List("Abraham Joe Lincoln, 34, President",
"George Ronald Washington, 29, President")
val output = MyObject.descriptorProcessing(input)
output should have length 2
output.head shouldBe()
}
}
"format descriptors" when {
"there is one input" in pending
}
}
}
I've used two features of scalatest that enable TDD, pendingUntilFixed and pending.
pendingUntilFixed lets you write a test for code that hasn't been implemented yet, or isn't working correctly yet. As long an assertion in the test fails, the test is ignored and displayed in yellow output. Once all the assertions pass, the test fails, letting you know that you can turn it on. This enables TDD, while allowing your build to pass before work is completed.
pending is a marker saying "I'm going to write a test for this, but I haven't gotten to it yet". I use this a lot, as it allows me to write an outline for my tests, then go back and fill them in.
Related
Here's what I'm trying to accomplish: I have a Chisel accelerator which calls another Chisel accelerator and passes in a value. I want the second one to have a while loop in it where the condition is partially based on the input value. Here's some sample code:
class Module1 extends Module {
val in = 0.U
val Module2Module = Module2()
Module2Module.io.in := in
}
class Module2 extends Module {
val io = IO(new Bundle {
val in = Input(Reg(UInt))
}
val test = 0.U
while (test < io.in) {
}
}
I'm getting the error that "test < io.in" is a chisel.Bool, not a Boolean. I know that I can't convert that to Scala types, right?
What is the proper way to implement this? Is it by having signals sent to/from Module1 to Module2 to indicate that the accelerator isn't done yet and to only proceed when it is? If so, wouldn't this get complex quickly, if you have several functions, each in different modules?
You will need to use registers, created by the Reg family of constructors and control the flow with when, elsewhen, and otherwise. I think a good example for you is in 2.6_testers2.ipynb of chisel bootcamp. The GCD circuit is equivalent to a while loop. The circuit continues until the y register is decremented to zero. Each clock cycle corresponds to a single iteration of a software while loop. The circuit uses the ready and valid fields of the Decoupled inputs and outputs to coordinate ingesting new data and reporting when a GCD value has been computed. Take a look at this example and see if you have more questions.
Just to elaborate on why you can't use a while loop with hardware values like chisel3.Bool, you can think about a chisel3 design as a Scala program that constructs a hardware design as it executes. When chisel3 runs, it is just running a program who's output is your circuit (ultimately emitted as Verilog). while is a Scala construct so it's only available during the execution of the program, it doesn't exist in the actual hardware. There's a similar question and answer about for loops on the chisel-users mailing list.
Now to answer your question, as Chick mentioned you can use the chisel3 constructs when, .elsewhen, and .otherwise to handle control flow in the actual hardware:
class Module2 extends Module {
val io = IO(new Bundle {
val in = Input(Reg(UInt))
}
val test = 0.U
when (test < io.in) {
// Logic for that applies when (or while) the condition is true
} .otherwise {
// Logic that applies when it isn't
}
}
Also as Chick mentioned, you'll likely need some state (using Regs) since you may need to do things over multiple clock cycles. It's hard to advise beyond this simple example without more info, but please expand on your question or ask more questions if you need more help.
If so, wouldn't this get complex quickly, if you have several functions, each in different modules?
I'm not sure how to answer this bit without more context, but the whole purpose of Chisel is to make it easier to create abstractions that allow you to handle complexity. Chisel enables software engineering when designing hardware.
How do I detect if a method is called by unit test in ScalaTest?
Edit: sorry, I was expressing wrongly the thing I wanted. I have a code block in a method which takes very long to finish (I cannot mock it) and it does not affect any logic. I want to skip that code block in the unit test. So I want to know whether it is called by unit test or normal running. If it is called by unit test, I skip it, otherwise, I let it runs normally.
I have a simple workaround by adding a trait like this:
trait AppConfig {
val isDebug:Boolean
}
use it in the places where I needs to check whether it is in debug mode:
class MyLogicClass {
_: AppConfig =>
def myMethod()={
if(isDebug){...}
}
}
Use a code coverage library such as scoverage for instance. It will generate reports that indicate you which parts of your code are used by unit tests.
I am reading online about cross cutting concerns since I just implemented Log4j into my code. Some people are saying using AspectJ is okay, while others point out that it breaks functional programming. That mixins are Scala's solution for cross cutting concerns.
However, I cringe when I think I will extend a trait to an object/ class that is not related itself.
e.g. new Database with Logger
Here Logger has nothing to do with Database, but its how to mixing to provide logging. I would prefer to do it the Scala way, so I want to find out this is what people mean by mixins.
Can someone please show me a quick example of how to go about this in Scala?
This is a big topic with lots of potential "correct" answers. My personal favourite would be using either "by name parameters" or higher order functions.
A a very simple example of this:
object Logging {
def logCall[T](name: String)(block: => T): T = {
log.info(s"Invoking: $name")
block
}
}
Which would allow you to apply it both in an object that itself knows about the cross cutting concern (something like annotating wrapping a method call with something in java):
class DB {
import Logging._
def insert(item: Something) = logCall("insert") {
???
}
}
Or at the call site:
import Logging._
def businessLogic() {
val user = ???
val result = logCall("insert user")(DB.insert(user))
println(result)
}
The nice thing with this is that it is very explicit and self explanatory (which, again, are things you might value high or not).
I'm trying to test-drive some Scala code using Specs2 and Mockito. I'm relatively new to all three, and having difficulty with the mocked methods returning null.
In the following (transcribed with some name changes)
"My Component's process(File)" should {
"pass file to Parser" in new modules {
val file = mock[File]
myComponent.process(file)
there was one(mockParser).parse(file)
}
"pass parse result to Translator" in new modules {
val file = mock[File]
val myType1 = mock[MyType1]
mockParser.parse(file) returns (Some(myType1))
myComponent.process(file)
there was one(mockTranslator).translate(myType1)
}
}
The "pass file to Parser" works until I add the translator call in the SUT, and then dies because the mockParser.parse method has returned a null, which the translator code can't take.
Similarly, the "pass parse result to Translator" passes until I try to use the translation result in the SUT.
The real code for both of these methods can never return null, but I don't know how to tell Mockito to make the expectations return usable results.
I can of course work around this by putting null checks in the SUT, but I'd rather not, as I'm making sure to never return nulls and instead using Option, None and Some.
Pointers to a good Scala/Specs2/Mockito tutorial would be wonderful, as would a simple example of how to change a line like
there was one(mockParser).parse(file)
to make it return something that allows continued execution in the SUT when it doesn't deal with nulls.
Flailing about trying to figure this out, I have tried changing that line to
there was one(mockParser).parse(file) returns myResult
with a value for myResult that is of the type I want returned. That gave me a compile error as it expects to find a MatchResult there rather than my return type.
If it matters, I'm using Scala 2.9.0.
If you don't have seen it, you can look the mock expectation page of the specs2 documentation.
In your code, the stub should be mockParser.parse(file) returns myResult
Edited after Don's edit:
There was a misunderstanding. The way you do it in your second example is the good one and you should do exactly the same in the first test:
val file = mock[File]
val myType1 = mock[MyType1]
mockParser.parse(file) returns (Some(myType1))
myComponent.process(file)
there was one(mockParser).parse(file)
The idea of unit testing with mock is always the same: explain how your mocks work (stubbing), execute, verify.
That should answer the question, now a personal advice:
Most of the time, except if you want to verify some algorithmic behavior (stop on first success, process a list in reverse order) you should not test expectation in your unit tests.
In your example, the process method should "translate things", thus your unit tests should focus on it: mock your parsers and translators, stub them and only check the result of the whole process. It's less fine grain but the goal of a unit test is not to check every step of a method. If you want to change the implementation, you should not have to modify a bunch of unit tests that verify each line of the method.
I have managed to solve this, though there may be a better solution, so I'm going to post my own answer, but not accept it immediately.
What I needed to do was supply a sensible default return value for the mock, in the form of an org.mockito.stubbing.Answer<T> with T being the return type.
I was able to do this with the following mock setup:
val defaultParseResult = new Answer[Option[MyType1]] {
def answer(p1: InvocationOnMock): Option[MyType1] = None
}
val mockParser = org.mockito.Mockito.mock(implicitly[ClassManifest[Parser]].erasure,
defaultParseResult).asInstanceOf[Parser]
after a bit of browsing of the source for the org.specs2.mock.Mockito trait and things it calls.
And now, instead of returning null, the parse returns None when not stubbed (including when it's expected as in the first test), which allows the test to pass with this value being used in the code under test.
I will likely make a test support method hiding the mess in the mockParser assignment, and letting me do the same for various return types, as I'm going to need the same capability with several return types just in this set of tests.
I couldn't locate support for a shorter way of doing this in org.specs2.mock.Mockito, but perhaps this will inspire Eric to add such. Nice to have the author in the conversation...
Edit
On further perusal of source, it occurred to me that I should be able to just call the method
def mock[T, A](implicit m: ClassManifest[T], a: org.mockito.stubbing.Answer[A]): T = org.mockito.Mockito.mock(implicitly[ClassManifest[T]].erasure, a).asInstanceOf[T]
defined in org.specs2.mock.MockitoMocker, which was in fact the inspiration for my solution above. But I can't figure out the call. mock is rather overloaded, and all my attempts seem to end up invoking a different version and not liking my parameters.
So it looks like Eric has already included support for this, but I don't understand how to get to it.
Update
I have defined a trait containing the following:
def mock[T, A](implicit m: ClassManifest[T], default: A): T = {
org.mockito.Mockito.mock(
implicitly[ClassManifest[T]].erasure,
new Answer[A] {
def answer(p1: InvocationOnMock): A = default
}).asInstanceOf[T]
}
and now by using that trait I can setup my mock as
implicit val defaultParseResult = None
val mockParser = mock[Parser,Option[MyType1]]
I don't after all need more usages of this in this particular test, as supplying a usable value for this makes all my tests work without null checks in the code under test. But it might be needed in other tests.
I'd still be interested in how to handle this issue without adding this trait.
Without the full it's difficult to say but can you please check that the method you're trying to mock is not a final method? Because in that case Mockito won't be able to mock it and will return null.
Another piece of advice, when something doesn't work, is to rewrite the code with Mockito in a standard JUnit test. Then, if it fails, your question might be best answered by someone on the Mockito mailing list.
I want to create a class at run-time in Scala. For now, just consider a simple case where I want to make the equivalent of a java bean with some attributes, I only know these attributes at run time.
How can I create the scala class? I am willing to create from scala source file if there is a way to compile it and load it at run time, I may want to as I sometimes have some complex function I want to add to the class. How can I do it?
I worry that the scala interpreter which I read about is sandboxing the interpreted code that it loads so that it won't be available to the general application hosting the interpreter? If this is the case, then I wouldn't be able to use the dynamically loaded scala class.
Anyway, the question is, how can I dynamically create a scala class at run time and use it in my application, best case is to load it from a scala source file at run time, something like interpreterSource("file.scala") and its loaded into my current runtime, second best case is some creation by calling methods ie. createClass(...) to create it at runtime.
Thanks, Phil
There's not enough information to know the best answer, but do remember that you're running on the JVM, so any techniques or bytecode engineering libraries valid for Java should also be valid here.
There are hundreds of techniques you might use, but the best choice depends totally on your exact use case, as many aren't general purpose. Here's a couple of ideas though:
For a simple bean, you may as well
just use a map, or look into the
DynaBean class from apache commons.
For more advanced behaviour you could
invoke the compiler explicitly and
then grab the resulting .class file
via a classloader (this is largely
how JSPs do it)
A parser and custom DSL fit well in
some cases. As does bean shell
scripting.
Check out the ScalaDays video here: http://days2010.scala-lang.org/node/138/146
which demonstrates the use of Scala as a JSR-223 compliant scripting language.
This should cover most scenarios where you'd want to evaluate Scala at runtime.
You'll also want to look at the email thread here: http://scala-programming-language.1934581.n4.nabble.com/Compiler-API-td1992165.html#a1992165
This contains the following sample code:
// We currently call the compiler directly
// To reduce coupling, we could instead use ant and the scalac ant task
import scala.tools.nsc.{Global, Settings}
import scala.tools.nsc.reporters.ConsoleReporter
{
// called in the event of a compilation error
def error(message: String): Nothing = ...
val settings = new Settings(error)
settings.outdir.value = classesDir.getPath
settings.deprecation.value = true // enable detailed deprecation warnings
settings.unchecked.value = true // enable detailed unchecked warnings
val reporter = new ConsoleReporter(settings)
val compiler = new Global(settings, reporter)
(new compiler.Run).compile(filenames)
reporter.printSummary
if (reporter.hasErrors || reporter.WARNING.count > 0)
{
...
}
}
val mainMethod: Method = {
val urls = Array[URL]( classesDir.toURL )
val loader = new URLClassLoader(urls)
try {
val clazz: Class = loader.loadClass(...)
val method: Method = clazz.getMethod("main", Array[Class]( classOf[Array[String]] ))
if (Modifier.isStatic(method.getModifiers)) {
method
} else {
...
}
} catch {
case cnf: ClassNotFoundException => ...
case nsm: NoSuchMethodException => ...
}
}
mainMethod.invoke(null, Array[Object]( args ))