Transcript Scalatest

Scalatest
26-Jul-16
Scalatest variants




Scalatest is a testing framework inspired by JUnit
Scalatest comes in various styles: FunSuite,
FlatSpec, FunSpec, WordSpec, FreeSpec, Spec,
PropSpec, and FeatureSpec
Examples of these can be seen at
http://www.scalatest.org/user_guide/selecting_a_style
The style I use (and talk about on these slides) is
FunSuite, because it’s most like JUnit, but you are
welcome to use whatever style you prefer
FunSuite example

import org.scalatest.FunSuite
class SetSuite extends FunSuite {
test("An empty Set should have size 0") {
assert(Set.empty.size == 0)
}
test("head of empty Set should produce NoSuchElementException") {
intercept[NoSuchElementException] {
Set.empty.head
}
}
}

Source: http://www.scalatest.org/user_guide/selecting_a_style
Three main methods



These methods, along with any arbitrary Scala code, should go within
test(Descriptive_string) {…}
Unfortunately, the syntax for each is different
assert(Boolean_condition)
assert(Boolean_condition, clue)



The clue is a String used to provide additional information about the failure
assertResult(expected_value) { compute_actual_value }
assertResult(expected_value, clue) { compute_actual_value }
intercept[name_of_exception] {
code that should throw the exception
}
withClue(clue) {
intercept[name_of_exception] {
code that should throw the exception
}
}
Don’t put too much in one test

Here’s an example test:



test("Testing Code.okToAdd") {
val code = new Code
assert(code.okToAdd('X', 'P'))
code.add('X', 'P')
assert(code.okToAdd('X', 'P'))
assert(code.okToAdd('A', 'B'))
assert(! code.okToAdd('X', 'B'))
assert(! code.okToAdd('Y', 'P'))
assert(! code.okToAdd('A', 'A'))
}
If any assertion fails, the rest of this test won’t be executed
Other tests will still be executed
before and after




Like JUnit, Scalatest has methods that are automatically
called before each test (to make sure each test starts in a
known state) and after each test (to clean up afterward)
before { code }
after { code }
As with JUnit, before is often used, after is seldom
used
Programming support

All major languages have significant support: IDEs,
test frameworks, active user groups, etc.


Because my primary concern in this course is concepts,
discussion of this support has been explicitly omitted
Scala has a few more concepts to cover, but most new
concepts in Scala are borrowed from other languages


My hope is that, in future, you will have opportunities to use
Scala
Therefore, I want you to use the Scala IDE and Scalatest
The Scala IDE

The Scala IDE is a customized version of Eclipse


Since Scala has had many fewer years of development than
Java, some Eclipse features (for example, History) don’t yet
work
Other IDEs, such as IntelliJ IDEA, have some Scala support,
but the Eclipse-based one is the “official” IDE
TDD, Test Driven Design/Development


Everyone in here should be familiar with TDD
If not, here’s a summary:








Write a test for the basic functionality of the method you intend to write
Write just enough of the method to pass the test
Refactor (clean up code without changing what it does)
If necessary, add features to the test
Add just enough to the method to pass the test
Refactor
Repeat until done
If, despite all the testing, an error is discovered later:


Write (or extend) a test to display the erroneous behaviour
Fix the error
Rules for all Scala programs in CIS 554

Methods should be of two types:

Methods that do computation and no I/O




Ideally, methods should be free of side effects
If a method does have side effects, those should not affect the results
of subsequent tests
All methods of this type should be tested with Scalatest
Methods that do I/O and no computation


Minimal computation can be done for purposes of formatting output
or putting input into a particular form
There is no need to use Scalatest for methods that do I/O
 It can be done, but it’s outside the scope of this course
The End