Even if you know nothing about ScalaTest it should be easy to understand whats this assertion is about. But what when your assertions get more complex? Like this:

Although this assertion certainly isn’t rocket science, it is not so easy to see what is getting tested here. How about this?

Now that is nice and clean and perfectly possible with ScalaTest. Of course we have to implement be_Greenish since ScalaTest doesn’t care so much about Frogs being green. Luckily the implementation is simple:

should expects a Matcher of what ever comes before should. So be_greenish must be a Matcher[Frog]. The Matcher has one method which we need to implement: apply and it takes a Frog as an argument and returns a MatchResult which we can construct using boolean signifying if the frog passed the test represented by the matcher or not, and the messages to use when the test failed and when the test succeed but actually was supposed fail. This makes it possible to negate assertions using not. There is also a variation of MessageResult which takes two more messages as arguments. Those are used when assertions get combined using and or or. In these cases the failure message of a Matcher are only part of a longer sentence and therefore probably shouldn’t start with a capital letter.

This approach would works really nice if we were testing some behavior of our frog. Like its ability to jump. We could create matcher that allow us to write things like:

jump would be a method taking a Distance as an argument and returning a Matcher[Frog]. far would be an instance of Distance.

But we really just want to test a property. This causes the weird name ‘be_Greenish’ with the odd underscore. There is a easier and therefore better way to write these matchers: BePropertyMatcher:

This allows us to write test like:

So whenever you write tests where the assertions are not trivial and possibly repeated in multiple tests consider to implement your own matchers. It’s easy and makes for way easier to read tests.

So naturally when working with ScalaTest I pretty soon wanted to have something equivalent to Rules. While you find not much when searching for ‘Rules ScalaTest’, it is actually quite easy to implement.

No matter what kind of tests you write with ScalaTest, at the end of the day the method def withFixture(aTest : NoArgTest) will get called with your test to execute. ‘Your test’ means in case of a FunSuite test the stuff between the curly braces that you pass to the test method.

The implementation of withFixture will finally execute your test. So all you have to do in order to get the equivalent of a JUnit Rule is to override withFixture. Lets give it a try:

This produces the following output on the console:

before
succeding test
after

before
failing test

As you can see, if you want to do stuff after the test, you better put it in a finally block, so it gets executed no matter if the test fails or not.

While this works, we don’t want to explicitly override withFixture every time we need our ‘rule’. The solution to this is to extract it into a trait:

The trait extends AbstractSuite, which makes withFixture available. It has a selftype of Suite, in order to ensure it gets only mixed into test suites.

So how does this solution compare to the implementation of a JUnit Rule? With a Junit Rule we have to create the actual Rule plus a Statement instance. With ScalaTest we only extend a single trait. Also since all this is standard Scala inheritance an no reflection involved, so it is pretty strait forward to find out how this works. While how and why a Rule gets executed is kind of tricky from the source alone. Finally you can explicitly control the order in which your traits apply, by controlling the order in which you put them in the extends clause:

before
3 before
succeding test
3 after
after

before
3 before
failing test
3 after
after

With Junit Rules there is currently no ready to use way to do this, but a feature to achieve this is in development.

While digging my way through various libraries I found a couple of different usage patterns, how traits are getting used. Here is what I found so far:

There are others that tell you the language doesn’t matter at least not between languages like Scala and Java. I think they are wrong as well. The reason is: Although I don’t actually use Scala during my day job it does affect my Java Coding. Here are some of the things I noticed.

• I appreciate immutability. I was aware for a long time of the benefits of immutability. But in Java using immutable data structures is so clumsy that I only used this approach in small areas, like rather simple value objects. But now I find my self more often tempted to use an immutable data structure even for relatively complex things.
• Lots of small classes. Classes in Scala are unbelievable small. It’s easy to write a single page of code with half a dozen classes in it if you count the ‘class’, ‘object’ and ‘trait’ keywords and even more when you look at what the Scala compiler creates from closures and similar. Although creating a class is much more work in Java I find myself thinking much strict about the single responsibility principle, resulting in more smaller classes, which are easier to test.
• Thinking more in DSLs. Scala is great for creating internal DSLs. Lots of libraries use that approach for designing their APIs and I do it in my little projects as well. Java is pretty useless for DSLs. But there are things you can do. Even if it is simple stuff like method chaining. I use that a lot lately, especially when testing is concerned, because here readability of code is even more important then with normal code.
• I pretty much gave up on Java Generics. After seeing what is possible with a good type system, even when the compiled code runs on the same JVM as Java, made me also see the severe limitations of Java Generics. Before that I tended to think its just me who is to stupid. While this assumption is often true. Many things I tried to do in the past with Java Generics just can’t work, because Java is lacking the necessary power (e.g. covariance and contravariance). So I drop generics from my code as soon as more then one type parameter gets involved.

So go ahead and learn a new language. Even if you can’t use it in your normal job. You still will learn useful stuff. But be warned. I might as well make you hate parts of your day job:

I really, really hate semicolons, primitives, arrays and collection APIs without higher order functions. And switching on Strings is a joke.

That’s not bad. It’s declarative and you can use the same annotation for your presentation model and your persistence model. If you use Hibernate for persistence it creates the right kind of constraint for the database as well. But there are a couple of shortcomings.

• If you want to do anything else with the information from the annotation you are forced to use ugly error prone reflection, which is especially bothersome, because a property consists of field getter and setter. So where exactly is the annotation? What if the annotation on the getter contradict the one on the field?
• You can’t abstract over the annotations. If comments should always have a minimum length of 5 and a maximum length of 500 there is no way to put this information in a proper abstraction. The best you can do is to define two constants.
• It doesn’t work with my Property class I introduced earlier.

The last point is obviously my own problem, but it also provides a starting point for a solution for the other shortcomings.

For those too lazy to read the referenced article, let me reintroduce the Property class. You define a Property like this:

This line of code is pretty much equivalent to this java code (with pcs being an instance of PropertyChangeSupport):

You can set its value (with p being an instance of what ever class contains the code above):

You can retrieve its value:

And you can register a listener on it

Back to validation. For age I only want to allow values between 9 and 99. How would you like to check if a given age is valid? Well, I would like to ask the property!

If I want to know what is wrong with the age value, I’d like to ask the property for a list of validation messages like this:

All you have to do for this, is to add a trait to the age Property

You can properly abstract over constraints as well by defining you own Property classes:

And it is easy to define your own Validations. Have look at the implementation of Length

There are a couple of simple rules for implementing a Validation:

• It has to have a selftype of Property
• You must override the method validate
• And when doing so you have to take care to append your validation messages to the results of super.validate. By doing this you make sure you can combine different validation traits.

validationMessages and valid aren’t methods but are Properties themselves. Therefor you can register listeners with them and bind your swing GUI to it. For example the following code snippet binds the validationMessages and valid to the tooltip and the visibility of label, resulting in a validation marker for a Property

If you are interested in more source code: Everything is up at github under the working title “moreThanProperties”. You can also find other related articles by looking for the tag moreThanProperties.

This might result in code like the one below. It is actually Scala code, but that shouldn’t matter much. The only piece that is a little special are the calls to Binder, which is a little Swing Binding Framework which I introduced a couple of weeks ago.

What is so bad about this piece of crap … ähm … code?

The method is long. 38 lines is about 10 times longer than healthy for a method.

There is tons of code duplication.

The method does lots of different things: creating components, adding them to a panel, configuring the layout.

There is a strong dependency on the order of commands. We can’t just move stuff up or down in the method and still hope the result will be something reasonable, even if we stick to rearrangements allowed by the compiler.

All this together makes the method extremely hard to understand. How long does it take to understand what kind of GUI results? Don’t bother to much, I help. It looks like this:

and if you resize it, it looks like this

Arguably the result looks just as ugly as the code, but once the code is clean we might be able to improve on the visual design as well.

If you don’t see it in the code, you might see it in the images: There are three different ways JComponents are handled by the method: JLabels are in the left column and don’t resize. The JTextFields are in the right column and do resize and the JButton doesn’t resize and is in the buttom right. In the code this is completely hidden in the manipulation of the GridBagConstraint. So lets make it explicit in the code:

I introduced three methods. One for adding a JLabel, one for adding a JComponent and one for adding JButtons. These handle the arrangement of components on a JPanel. The total length of the code increased because we create the GridBagConstraints insided the methods and have to set all properties and don’t rely anymore on the previous step to leave the constraint in a specific state.

If we now look at the createPersonPanel we’ll get a strong fealing of repetition in various places:

• each call to add* methods takes the same JPanel as an argument. We can improve on this by creating a Builder wich crates the panel, contains the add* methods and can return the fully configured panel at the end.
• for each property we create a JLabel, a JTextField, bind the property to the later and add both to the JPanel. We can fix this by encapsulating it in a seperate method.

The result might look like this:

The PanelBuilder has now two simple public add methods. In order to imitate the method signitures in Java we would have to create a couple of helper classes and interfaces. It would make the code less compact but this shouldn’t be a serious problem. Creation of the various components is just as the binding extracted in two create Methods. The createPersonPanel has now only 5 lines of code. Adding another property to the form should be trivial. Changing the extremely simplistic layout should be trivial and is at least limited to a single small class. I think this is pretty much OK for a first step toward clean swing code. So I leave it like it is right now. Although I do have further plans for this.

I hope most of you agree that the code is much easier to understand and maintain in the form it is right now. But is it really worth the effort? Some might say no. If the whole application would consist of only this little panel. I would agree. But a Swing application typically does not have a single panel with two textfields and a button. But tens or even hundreds of panels. Many consisting of large collections of components. If you have to maintain such a monster, would you prefer createPersonPanel methods like the last one, or would you prefer the first version? What if the customer if finally fed up with your crappy layout and insists on proper spacing between the labels and the JTextFields or other components?

All this is pretty nice when you start a new Swing application. But what if you have an existing Swing application? One with convoluted code just as the Swing Tutorial taught you? Well … start changing it now. Don’t sit down for two months and rewrite all your code, but find pieces of code duplication and extract them. It will be a long way, but you wont reach the end if you don’t start walking.

But what if you are not using Swing, but writing a web application? Well it really shouldn’t matter much. Your PanelBuilder might be written in JavaScript, or create HTML, but the principle is the same: Seperate creation of components, layout of components and binding of components to properties and actions.

Having properties like this you can bind them to Swing components using JGoodies Binding like this:

If you don’t know JGoodies Binding you should read this article about it asap.

If you do form based Swing applications this is the way to go: don’t write Listeners, bind components.

Yet I have a huge problem with this code. Actually multiple problems:

• You have to repeat the name of the property in four places and you will end up in hell if you don’t do it in the correct way: In the name of the setter, in the name of the getter, in the first argument to firePropertyChange and in the call to the binding framework.
• A trivial property takes 8 lines of code. Thats EIGHT lines of code. Or depending on your code quality probably about 1/100th to 1/10th of a bug, for a trivial property.
• Apart from being to much code, it also has a high degree of duplication, because it is the same pattern over and over again. Yet their doesn’t seem to be a reasonable way to abstract over this kind of thing

If you are willing to switch to another language you actually can abstract over this quite nicely. This of course in no surprise, since it should be easy to write a language that offers support for this kind of property. But that is not what I’m talking about. I’m of course talking about a little Scala goodness. How about this for defining a class with a property:

Note that there is only one line defining the property (including setting it to an initial value). So how would binding it to a JTextField look like? Like this:

Note that I don’t use the String “name” anywhere. Its all just normal, strongly typed values. If I use firstName instead of name by accident, the compiler will complain. The trick is obviously that I actually use objects of type Property, instead of fields, getters and setters. Yet using this thing looks (almost) perfect natural:

The code to achieve this is rather simple and short. The key is that a Property has a apply method returning its value and an := operator as replacement for a setter.

This is currently just a little toy, call it proof of concept if you like. It only works with JTextFields, and the event notification might needs tweaking, since it provides just the new value of the property right now. There are many more ideas how to use this as a basis for building nice clean code with a Swing GUI. Watch this blog for more ideas and toys like this.

In JUnit 3 for you did that by overriding the methods setup() and teardown() of the class TestCase, which every test needed to extend. JUnit 4 was a little more flexible. The name of the methods was irrelevant, instead you used annotations to tag the methods you wanted to use for setup or teardown. The anotations where are @Before, @BeforeClass, @After and @AfterClass. This lead to the somewhat messy situation where the setup of a test was sometimes called setup, sometimes Before and sometime it was given a name that actually described what it was doing like createAnEmptyStack(). As a result the setup and teardown methods weren’t easily identified any more.

How does ScalaTest solve the issue? It goes back to the inheritance solution, but benefits from the possibility to inherit from multiple traits. So you can still have tests that extend some completely unrelated trait. As so often scalatest offers multiple option. For JUnit developers the following is probably the most intuitive:

We mix two traits BeforeAndAfterEach and BeforeAndAfterAll into our test class, which allows as to override before/afterEach and before/afterAll which get executed as probably expected yielding the following output:

beforeEach
inside the test
afterEach
beforeEach
inside the test
afterEach
afterAll

If you are using this technique to setup some variables that get used inside the test, note that there is only on instance of the test class no matter how many tests it contains. So make sure you clean everything up after your test. Since cleaning up is error prone there are other strategies you can use. You can use the OneInstancePerTest trait, which ensures that each test as its own test instance, as you are used to from JUnit.

I consider different approach more idiomatic for Scala(Test): pass the stuff you need inside your test into the test as a parameter! In order to do this for every Suite trait (like e.g. FunSuite) there is a matching Fixture* trait. Let’s examine an example using the FixtureFunSuite. In order to make it work we need to do three things:

1. specify what kind of fixture our tests expect. We do this by defining the type FixtureParam inside the test class
2. the tests actually have to accept a fixture of that type as a parameter
3. we have have to create the FixtureParam objects and pass them into the tests when calling them for execution. This happens in the method withFixture

Note that both tests would fail if they would see the changes done by the other tests, but they don’t. For just doing normal setup, this approach might be a little to verbose, but consider that you have full control over how you call the tests. You could use this in order to run each test 20 times in parallel threads in order to test for concurrency problems, or in the EDT of Swing for swing related tests. Faithful readers might remember such a list from a different article: It is exactly the kind of stuff you can do with JUnit Rules.

If you read so far you might as well be interested in Testing with Scala and More on Testing with Scalatest

These systems often work with some kind of visual interface, which allows to drag and drop commands. Thats great for kids that are used to a mouse a lot. While my son is certainly able to use a mouse, drag’n'drop is something taking full concentration for him. And when something drops in the wrong spot it is often quite difficult for him to figure out what happened.

At the same time I was reading Structure and Interpretation of Computer Programs which will teach you among other things Scheme. And I was amazed at the simplicity of the first program:

486

It will print 486. Not exacty a master piece of algorithm design, but you have to admit it is extremely easy. My son sure could do that. But I don’t know Lisp or Scheme and I am a JVM guy. So I considered learning Clojure, until I remembered the Scala REPL. The Scala REPL is an interactive console based environment which will interpret you input as Scala code. So I fired it up typing <tt>scala</tt> in the command line and tried the program mentioned above:

Scala REPL showing the simplest possible Scala programm: 486 (click for full size)

So I started teaching Scala to my son. The first programs where things like

2+3

After trying different expressions I introduced the concept of variables and dictated:

val lara = 3

Explaining that ‘lara’ has now the value 3

He immediately grasped the concept and tried the following

finn = 6

which resulted in

:8: error: not found: value finn
val synthvar$0 = finn
                 ^
:5: error: not found: value finn
       finn = 6
       ^

Since Finn can’t read yet and doesn’t speak English either there was no way he would understand the error message. So the only chance was comparing the command that worked and the command that doesn’t until he figured out what was wrong.

I think that was the very first big lesson learned: Computers are extremely picky about what they are willing to understand.

After understanding that he missed the ‘val’ thingy at the beginning he declared a variable for himself, one for mom and one for dad, each filled with the respective age and added the ages until it was time to finish the first lesson of Scala programming.

So what are the lessons I learned from this?

• visual interfaces can be a distraction
• the simplest Scala program is by orders of magnitude easier then the simplest Java program. If you doubt that write down the simplest Java program and compare it to 486 and then add the steps of saving the file, compiling and running it to the equation.
• If you don’t have much to build on even the visual programming environments designed especially for kids are more difficult to master then the first steps in Scala

BTW: When we continued with the second lesson (repetition of what we learned + functions) Finn started to teach the stuff he learned to his younger sister (3 years old). I’ll tell that anybody who tries to explain to me that he doesn’t know anything worth telling others in a Java User Group.

I described one way of testing with scalatest using FeatureSpec. But there are many ways in which you can write tests. So just for the fun of it I’m using the FunSuite today:

This looks similar easy enough for every Java developer to to understand what is going to be tested. It might not be so obvious, what actually is going on in this class. Lets ignore the actual assertions for today. Note that we don’t define anything but the test class itself. So the the individual tests aren’t method definitions as in JUnit (and TestNG AFAIK), but calls to a function called test. It takes two arguments: the name of the test (which has to be unique in the test class) and the actual test which is just a code block. (Actually you can have additional tags after the test name, but again thats for a different article. The method test registers the test for execution. This happens at instantiation of the test class, since the calls to the test method are placed directly in the body of the test class. Once all the test classes are instantiated (and therefore all tests registered) scalatest starts executing all the tests, i.e. it executes all the code blocks passed as parameters to test.

As you might have noted, there was no ‘reflection’ or ‘byte code magic’ involved in all this. It’s all straight scala code. I guess Bill Venners liked that when he was writing the code. But why should we as a user care? Because we can do all the things we can do with normal code!

Lets assume you wrote a method to check if a string is a palindrome obviously you want to have some tests for that:

While the tests in this example are really simple we still see the code duplication. And once the tests get just a little more involved, it gets really annoying. But since tests are just method calls we can rewrite like this:

I start by creating a Map from the expected result of the method palindrome to a list of test values which should yield that result. I then loop through that Map and the contained list and for each entry I call test, with a dynamic name and a fixed code block.

To do the same thing in JUnit or TestNG you have to use special features of the test frameworks. With scalatest its just a basic application of language features. I like that.