I am a software developer from Poland, currently working in banking industry. For the past few years I have been writing software in Java, however I actively seek for a close alternative. Certified in SCJP, SCJD, SCWCD and SCBCD, used to be active on StackOverflow. I feel comfortable at the back-end, however recently rediscovered front-end development. In spare time I love cycling. Tomasz is a DZone MVB and is not an employee of DZone and has posted 86 posts at DZone. You can read more from them at their website. View Full User Profile

FitNesse your ScalaTest with custom Scala DSL

04.10.2013
| 732 views |
  • submit to reddit

This article won't be about FitNesse. As matter of fact I don't like this tool very much and it seems to be loosing momentum, judging by the traffic on an official mailing list. Instead we will implement trivial internal DSL on top of Scala to simplify testing code, inspired by DoFixture. DoFixture in FitNesse allows one to write very readable acceptance tests almost in plain English using Wiki pages:

!|CarRegistrationFixtureTest|
 
!1 Registering car
!2 Registering brand new car for the first time
 
| register | brand new car | by | any owner | in | any country |

What might not be obvious is that the last line is actually executable and calls good old Java (or Scala for that matter) method:

class CarRegistrationFixtureTest extends DoFixture {
 
    val carService = new CarService
 
    def registerByIn(car: Car, owner: Owner, where: Country) = {
        //...
    }
 
}

Notice how oddly named registerByIn method maps to " register brand new car by any owner in any country" wiki syntax. What we will learn today is writing very simple, custom Scala DSL that is even more readable and does not require new tool and testing framework.

The same test written in ScalaTest would look something like this:

class CarRegistrationSpec extends FeatureSpec with GivenWhenThen {
 
    val carService = new CarService()
 
    feature("Registering car") {
 
        scenario("Registering brand new car for the first time") {
            Given("Owner and brand new car")
            //...
 
            When("Car registered")
            carService.registerCar(brandNewCar, anyOwner, anyCountry)
 
            //...
        }
    }
}

Nothing fancy, ordinary registerCar() method call. The rest of the test (as well as the declaration of brandNewCar, anyOwner and anyCountry) is not relevant to our discussion. We can make it a little bit more readable by explicitly naming parameters:

carService.registerCar(car = brandNewCar, owner = anyOwner, where = anyCountry)

This is as far as Java can go, but Scala has infix method call syntax, which is equivalent and looks beautiful:

register(brandNewCar) by anyOwner in anyCountry

Why couldn't we skip first parentheses? It is a limitation on where infix notation can be used (only one-argument method calls on an object). Fortunately we can easily refactor our internal testing DSL by pushing noun (owner) onto first place and using implicit conversion:

implicit def fluentCarRegister(owner: Owner) = new {
    def registers(car: Car) = new {
        def in(country: Country) =
            carService.registerCar(car, owner, country)
    }
}

...which can be used as follows:

anyOwner registers brandNewCar in anyCountry

If you got lost, the line of code above is still Scala and is still executable. If you don't quite get what's happening, here is a desugared syntax:

fluentCarRegister(anyOwner).registers(brandNewCar).in(anyCountry)

Tests are all about readability and maintainability. Many people are scared of DSLs because often they are hard to implement and debug. As I showed in this short article, writing really simple yet impressive test DSL in Scala is both simple and rewarding. Moreover there is no reflection or magic meta-programming.



Published at DZone with permission of Tomasz Nurkiewicz, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)