The fugue theme shown in a stretto here is almost just a scale.

If you invent a new computer programming language, you should probably also invent a new testing framework to go with it.

However, if the new language is for the Java Virtual Machine (JVM), why not just use JUnit?

Scala, as you might already know, is an object-oriented functional language for the JVM invented by Martin Odersky, author of the Java 1.3 compiler.

There is ScalaTest, which definitely has some features to recommend it. But once you get Scala working in IntelliJ, using JUnit is super easy and requires no additional setup.

For the project into which I’m gradually adding Scala classes, a program to draw diagrams of prime numbers in certain imaginary domains, I created the class ImagQuadInt to mirror ImaginaryQuadraticInteger and ImagQuadRing to mirror ImaginaryQuadraticRing for smoother use in the Scala REPL, which I wrote about a few weeks ago.

It’s also a project I’m gradually switching over to test-driven development. Since the Scala classes I’ve added are just, as Cay Horstmann would call it, “a thin paste” on Java classes, I didn’t consider it necessary to write tests for them.

For instance, ImagQuadInt.+ is just a version of that takes advantage of operator overloading in Scala. Here is a quick quote of the latter with a lot left out:

I think I have tested this quite thoroughly, so there’s probably not much to be gained from testing its simple Scala wrapper, which is now quoted in its entirety:

Oops, that’s the one to add a purely real Int to an ImagQuadInt. Well, the one I meant to quote is not that different.

Once I started thinking about how to do test-driven development in Scala, though, I realized I might as well use ImagQuadInt to try out the basics of using a testing framework with Scala in IntelliJ.

There are quite a few wrinkles to the process. First of all, if you ask IntelliJ to auto-generate a test class with test stubs, it will generate a new Java class in the test folder, not a new Scala class. I’m guessing it’s the same in NetBeans.

But with all the auto-complete IntelliJ does, it is not too big a deal to create a new almost empty Scala file in the test folder and then start writing into it the JUnit imports.

You can put in semicolons if you want. Note that the underscore is the wildcard character in Scala, not the asterisk like in Java.

I suppose that as I develop this, I might need @BeforeClass and the like. For now, this is enough to start getting into it.

As my classmates at Integrate Detroit like to remind me, test is not necessary in the test subroutine name for JUnit 4.

I could call that first test just +, but that would be confusing, and an argument against operator overloading. So I’m going with testPlus, just as in ImaginaryQuadraticIntegerTest.

On thing I really don’t like about Scala is that void is called Unit. Quite confusing. It should have been called Void, in my opinion.

IntelliJ should show green play buttons next to the tests. Now you can run them just as you would any ordinary JUnit test in Java.

To test that exceptions are thrown when they should, almost everyone prefers to use JUnit’s annotation argument expected to the good old-fashioned try-catch-with-fail, but in Scala there’s a major wrinkle that I would not have figured out on my own.

With ScalaTest I could do

which I like a heck of a lot better, but which I haven’t yet figured out how to do it in IntelliJ yet. Adding the lines

is the easiest part of the setup. Messing with the project build dependencies… I’ll have to figure that out another time.

Any time you want to give your testing of exceptions a little bit more foresight, you’re probably going to have to go with the good old try-catch with fail.

For example, it has always seemed strange to me that division by zero in Java’s primitive numeric types causes ArithmeticException. I think IllegalArgumentException makes more sense.

A reasonable argument could even be made for NotDivisibleException for classes implementing the AlgebraicInteger interface. That’s something I’ve been going back and forth on.

But although TestNG does have the capability to declare multiple expected exceptions (I’m guessing that the test passes as long as one of the listed exceptions is thrown), it looks like JUnit still doesn’t have that capability.

ScalaTest might, I don’t know yet. Then for now, my division by zero test looks like this:

The pertinent code is at GitHub.

is a composer and photographer from Detroit, Michigan. He has been working on a Java program to display certain mathematical diagrams.