Schauderhaft » trait

Ratchet Tests with ScalaTest

Jens Schauder — Sun, 18 Sep 2011 04:17:21 +0000

Ever found more broken things in a project than you possible could fix in one go? I’m exactly in that situation. We have a test which checks for certain dependencies in our project. The problem: We discovered that the test was broken and didn’t report all disallowed dependencies. We do know how to fix it, but if we do it will fail. And since there are many violations it will take quite some time to fix all of them. But of course we want to prevent even more violations of our dependency rules.

The solution could be a ratchet on the tests. A contraption which accepts broken tests, but which doesn’t allow tests to fail once they succeeded.

For ScalaTest you can create appropriate tests using this simple Ratchet trait

package de.schauderhaft.ratchet
import org.scalatest.AbstractSuite
import org.scalatest.Suite
import org.scalatest.TestFailedException
trait Ratchet extends AbstractSuite {
self : Suite =>
private var tests = Set[String]()
def ratchet(ratchetedTests : Set[String]) {
tests = ratchetedTests
}
override abstract def withFixture(theTest : NoArgTest) {
if (tests.contains(theTest.name)) {
var failedToFail = false
try {
super.withFixture(theTest)
failedToFail = true
} catch {
case ex : TestFailedException =>
}
if (failedToFail)
fail("Remove '%s' from the ratchet it doesn't fail anymore".format(theTest.name))
} else
super.withFixture(theTest)
}
}

It adds a ratchet method to your suite. You pass it a Set of test names. These are the tests that you expect to fail. If they do fail, the Ratchet will convert that failure to a success. If a test which you expect to fail succeeds, the Ratchet will make sure it does fail with a message saying you should remove it from the tests expected to fail. Tests not registered with the ratchet method behave just as normal tests do. This is how the contraption looks in action with an example test suite: (Note tests which start witch ‘expected:’ do fail

class RatchetTestDemo extends FunSuite with ShouldMatchers with Ratchet {
ratchet(Set(
"a failing test with ratchet does not fail",
"expected: a succeeding test with ratchet fails"))
test("a failing test with ratchet does not fail") {
fail
}
test("expected: a failing test without ratchet fails") {
fail
}
test("a succeeding test without ratchet succeeds") {
}
test("expected: a succeeding test with ratchet fails") {
println("hallo")
}
}

Usage Patterns of Scala Traits

Jens Schauder — Sun, 21 Aug 2011 11:28:10 +0000

One of the many cool features in Scala are traits. traits are like a mixture of abstract classes and interfaces: You can ‘implement’ as many of them as you want just as with interfaces, but they can also contain implementation, which makes them similar to abstract classes. You also can’t instantiate a trait on its own, so there is another similarity to abstract classes.

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:

The Introvert Trait: These are traits that aren’t intended for changing the behavior of a class for outside clients of the class, but for the code inside the class itself. They often make an internal DSL available. An example are the ShouldMatchers in ScalaTest. You mix in this trait into your test class in order to use syntax like someValueToTest should be (23) The problem with this kind of usage is that you can’t really control the scope in which your trait/DSL applies. So if you want to use two such traits which happen do define the same method or operator with different meaning you are in trouble. Often you can replace the trait with an object which you import. Since scoping rules apply for imports as well you can control much better which part of your class have access to that object. I see two reasons why this kind of trait makes sense: It makes the presence of the trait/DSL very obvious since it is right next in the beginning of the class declaration, while an import statement might get overlooked. The other reason is, if you want to fool around with self types, i.e. you want to limit the kind of classes the trait can get mixed in to or if you want to reference that class.

Classes with dissociative identity disorder: Sometimes things are two things at once. A wooden chair might be furniture as well as fuel for an oven. A square is a rectangle and a rhombus. This works perfectly with traits. While in java you would often have two interface, but one class implementing both, you can easily split the implementation between two traits in scala. Nice. But you should carefully check if these two behaviors actually belong in a single class, or if you are violating the Single Responsibility Principle.

The Jigsaw Puzzle Trait: In this pattern traits are used to separate different aspects of a responsibility in a very fine grained manner. The results are traits that are really hard to understand on their own. Actually they are easy to understand since the often only consist of half a dozen lines of code. What is difficult is to understand how this can be useful in any way. Yet if done right it allows do reduce code duplication to an absolute minimum. The best example for this usage is the Scala collection API. It consists of a huge number of traits, that get assembled in different ways in order to form the different classes.
The Steam Roller Trait: What happens when you drive a steam roller over something small, let’s say an interface? It gets very wide. This is another technique used in the Scala Collection API. The trait defines a self type, either using another trait or a structural type and defines lots of other stuff based on that interface. This completely solves one of the basic challenges in Java interface design: If you define wide interfaces, i.e. interfaces with lots of methods, it increases the chances for users to find the method they need. On the other hand those poor bastards who have to implement such an interface have a lot of work to do. If you have any doubts how powerful this pattern is, check out how little code you have to write in order to create a new collection implementation which nicely integrates with all the others and has hundreds of methods just like all the other Scala collections as well.

Mixins, Inheritance and Delegation

Jens Schauder — Sun, 24 Jan 2010 11:27:49 +0000

Blender

A week ago I started learning Scala. One of the features I found pretty interesting are mixins and traits. That was just the point of time, when I read this little tweet of GeekyL:

“i am still not sure if mixins are super cool or dark magic.”

Of course I was instantly reminded of the time when the dinosaurs dominated the world and I was learning the first little bits of OO and C++. I thought inheritance and polymorphism was great and the solution for every possible programming problem there is. It turned out that was not the case. Actually inheritance can result in pretty ugly code.

So GeekyL’s tweet got me thinking: Do mixins have the same problem? What exactly are the problems with inheritance anyway? Time for a new blog post.

What are the problems of inheritance?

Inheritance for code reuse: It is tempting to have a class inherit from a superclass just because the superclass has some useful feature. Like this.

import java.beans.PropertyChangeSupport;

public class PropertySupport {
protected PropertyChangeSupport propSup;
}
public class UserEntity extends PropertySupport {
private String firstName;
public void setFirstName(String aFirstName) {
String oldValue = firstName;
firstName = aFirstName;
propSup.firePropertyChange("firstName", oldValue, firstName);
}
}

The problem with such code is that inheritance suggests a is-a-relationship, which in this case is just wrong. A UserEntity is not a PropertySupport, it just uses one.

Multiple inheritance: At least in java a class can only inherit from one superclass. But many classes are many things. For example, a Cat is a Carnivor, it is a FourLeggedAnimal and a FurryAnimal. Without multiple inheritance there is just no way how to model this with class inheritance. With multple inheritance you can extend all these classes at the same time, but now you inherit the top class Animal three times, which at least is ugly.

So the proper way to do this kind of stuff in java is to use delegation and interfaces:

public class Cat implements Furry, FourLegged {

FurryDelegate fd;
FourLeggedDelegate fld;
@Override
public void pet() {
fd.pet();
}
@Override
public void runFast() {
fld.runFast();
}
}

Which works in the sense that you can pretty much express the kind of things you need to do, and which you might be tempted to solve with class inheritance. Of course the draw back is that you’ll have to create all theses trivial delegate methods.

In Scala you have the option to use Traits. Like so

class Animal

class Cat extends Animal with Furry with FourLegs{
}
trait Furry{
def pet() {
println("purrrrr")
}
}
trait FourLegs{
def runFast() {
println("I'm gone")
}
}

Obviously this contains much less code duplication then the java version. Does it have drawbacks? You bet.

Mixins are firmly tied to the traits they use. Imagine a more complex trait, which itself uses many other clases and resources. Once you mix in such a trait you have a strong dependency. Therefor I suggest the following pattern for getting the reduction of code duplication from traits and the flexibility of delegates: Use Traits, which don’t have a real implementation, but use a delegate for doing all the real stuff, this way you can switch the implementation with touching just a single place:

class Superclass

class Mixin extends Superclass with Trait {
// … more stuff goes here
}
trait Trait {
val delegate = new TraitImpl // this should be some kind of DI or lookup in a real system
def aMethod() {
delegate.aMethod()
}
}
class TraitImpl extends Trait {
override def aMethod(){
println("you just called me")
}
}

Summary: Traits can be used to solve some of the problems of inheritance, but they might introduce strong coupling, which you can easily be avoided.