As I’ve written before, when I finished writing the Scala Cookbook it ended up being about 140 pages longer than my editor wanted, and I had to cut some content from the book. Unfortunately the chapter on “Logging & Testing” was one of the victims of the cut, but I’m glad to say that I’ve finally taken the time to convert that material to HTML. As a result, here are links to the 12 ScalaTest tutorials in that chapter:
For the first time in many years I just came across Kent Beck’s Four Rules of Software Design:
- Passes the tests
- Reveals intention (should be easy to understand)
- No duplication (DRY)
- Fewest elements (remove anything that doesn’t serve the three previous rules)
There are wording variations on those rules, but I got those specific words from this Martin Fowler post. As he notes, “The rules are in priority order, so ‘passes the tests’ takes priority over ‘reveals intention.’”
For more information on Kent Beck’s Four Rules of Software Design, see that link, or this link to the original rules on c2.com.
Problem: You want to use a mock object framework in your ScalaTest tests, such as Mockito.
ScalaTest offers support for the following mock testing frameworks:
Because the support for each framework is similar, let’s take a look at using Mockito.
Before starting, imagine that you have a login web service for your application, and rather than call the real web service during your tests, you just want to mock one up.
Problem: When using ScalaTest, you want to temporarily disable one or more tests, presumably until you can get them working again.
When using BDD-style tests, change
it method calls to
Problem: You want a way to label your individual ScalaTest unit tests, so you can easily choose to include or exclude them when running your test suite. For instance, you may want to tag long-running tests like database or web service tests, because they take a long time to run, and you don’t want to run them all the time.
Create one or more custom tags, then include those tags in your test specifications. When you run your tests, declare which tests you want to run, or not run.
Problem: You want to use test-driven development (TDD) style tests in your Scala applications, and need to see examples of how to write them.
Have your test classes extend the ScalaTest
FunSuite, and then write your tests. Because most tests involve a setup and teardown process, you’ll usually also want to add in the
BeforeAndAfter trait as well.
I started using a tool named Cobertura to generate code coverage reports lately, and I have to say that I've been very happy with the results. If you are a believer in test driven development, or TDD, the next step in the process is code coverage.
While reading a book on TDD (Test Driven Development) from Kent Beck, I ran across a reference to Jester, which is apparently a JUnit test tester. Like many things lately, I haven't tested it yet myself, but it claims to "find code that is not covered by tests". If it works, that would be pretty cool.