Apart from a little work to make it compatible with the most recent versions of Scala and ScalaTest (thanks to Chua Chee Seng, Duncan Crawford and Chris Birchall) ScalaMock has been moribund over the last 12 months. This is partly because my focus has been on writing Seven Concurrency Models in Seven Weeks, but mostly because of insurmountable issues with Scala’s current macro support.

There is good news on both fronts, however. First, I recently finished the book, so I should now have more time to devote to ScalaMock. And second, Eugene has announced Palladium, which looks like it should provide everything that ScalaMock needs.

So where is ScalaMock now? And where is it (hopefully) going?

Where is ScalaMock today?

ScalaMock 3 supports two types of mock, proxy mocks and macro mocks.

Proxy mocks are not type checked and have a slightly less convenient syntax than macro mocks, but they work with any trait and are fully supported.

Macro mocks are type checked and have a nicer syntax than proxy mocks. They work well with most traits, but fail for traits with “complex” type signatures.

The good news is that macro mocks either work or give a compile error (there should be no situations where a macro mock compiles but gives “odd” results). And if you have a trait for which macro mocks don’t work, you can always use a proxy mock instead.

Where is ScalaMock going?

As soon as Palladium is available, I plan to start working on ScalaMock 4. If Palladium delivers on its promise, ScalaMock 4 should be able to mock any trait, no matter how complex its type. In addition, I expect that it will also support:

Improved syntax:
mockObject.expects.method(arguments)

instead of:

(mockObject.method _) expects (arguments)

Mocking object creation (constructors)
Mocking singleton and companion objects (static methods)
Mocking final classes and classes with final methods or private constructors