Kent Beck’s Four Rules of Software Design (also known as “Simple Design”) alvin May 7, 2018 - 5:32pm

For the first time in many years I just came across Kent Beck’s Four Rules of Software Design:

  1. Passes the tests
  2. Reveals intention (should be easy to understand)
  3. No duplication (DRY)
  4. 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

12 ScalaTest tutorials

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:

ScalaTest 111: How to use Mock objects with ScalaTest

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:

  • ScalaMock
  • EasyMock
  • JMock
  • Mockito

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.

ScalaTest 110: Temporarily disabling unit tests

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 ignore:

ScalaTest 109: Mark your tests with tags to include or exclude them

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.

ScalaTest 102: Writing TDD style unit tests with ScalaTest

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.

Software code coverage and automated testing

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.

Sat, Feb 8, 2003 alvin February 8, 2003 - 9:49am

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.