Language Feature Request

Maybe this feature exists in some language, I'm not sure. My inexperience is letting me down. :( Here is what I want, as demonstrated in Scala.

I want to be able to use the name of my variable programmatically. So, instead of having to give my objects names like this:

case class Server( name: String )
val server = Server("Altair")
println(server)

Which yields: Server("Altair")


or like this:

class Server( name: String ){ override def toString = name }
val server = new Server("Altair")
println(server)

Which yields simply: Altair


I would like something like this:

case class Server extends VariableName
val Altair = new Server
println(Altair)

Which yields simply: Altair

That example shows it as simply a library. It probably can't be done as a library, so it seems like it would have to be a language feature. Something like this.

varname case class Server
val Altair = new Server
println(Altair)

Which yields simply: Altair


Does anything like this exist? Would it be terribly difficult to build into a compiler? Things would probably be tricky if you said something like...

varname case class Server
val Altair = new Server
val Moxy = Altair
println(Moxy)

Would you want to get Altair, or Moxy?

Can anyone give any opinions on this at all?

Using Scala Actors

I'm assuming (maybe incorrectly) that most of the Actors that will be written will simply want to react to messages, forever. Something like this:

val reactor = new Actor(){ 
  def act() { 
    loop{ 
      react{
        case msg => ...
      } 
    } 
  } 
}

Given that assumption, it seems like it would be nice just to define whats in the react portion of the code. The rest is redundant. This is pretty simple. First, I created a simple little factory called Actors.

object Actors{
  def newReactor( f: PartialFunction[Any,Unit] ): Actor = { 
    new Actor(){ def act() { loop{ react(f) } } }
  }
}

and then I simply used it:

val reactor = Actors.newReactor {
  case msg => println( "Got something: " + msg )
}

This consolidated the code outside the actual reaction from 4 lines (and 4 right brackets) to a single line (and a single right bracket).

You can also do some other interesting which allow you to keep your reaction code separate from the actual actors (you can do this using the original approach as well). You can define partial functions, and pass them into the newReactor method like this:

def normalReaction : PartialFunction[Any,Unit] = {
  case x: int => println( "Got int: " + x )
  case msg => println( "Got something else: " + msg )
}
  
def abnormalReaction : PartialFunction[Any,Unit] = {
  case msg => println("eruhewiurhqweihu!!!!")
}

val normalReactor = Actors.newReactor { normalReaction } 
val abnormalReactor = Actors.newReactor { abnormalReaction } 

I know this is all rather simple and trivial, but I'm crazy about reducing redundancy and improving readability.

Scala and Enums

Scala doesn't have language level support for enumerations, but I think its fairly easy to argue that its a good thing. First, something isn't quite right about Java enums. Sometime soon I'll post more about that. Scala is such a nice language that you can do things cleanly without needing built in support for extra things like enum. Extra features in a language clutter it up.

As an example, I lovingly ripped off the Planets example from the Java tutorial itself, and implemented it in Scala. Here is the Scala code.

case object MERCURY extends Planet(3.303e+23, 2.4397e6)
case object VENUS extends Planet(4.869e+24, 6.0518e6)
case object EARTH extends Planet(5.976e+24, 6.37814e6)
case object MARS extends Planet(6.421e+23, 3.3972e6)
case object JUPITER extends Planet(1.9e+27,   7.1492e7)
case object SATURN extends Planet(5.688e+26, 6.0268e7)
case object URANUS extends Planet(8.686e+25, 2.5559e7)
case object NEPTUNE extends Planet(1.024e+26, 2.4746e7)
case object PLUTO extends Planet(1.27e+22,  1.137e6)

// mass in kilograms, radius in meters
sealed case class Planet( mass: double, radius: double ){
    // universal gravitational constant  (m3 kg-1 s-2)
    val G = 6.67300E-11      
    def surfaceGravity = G * mass / (radius * radius)
    def surfaceWeight(otherMass: double) = otherMass * surfaceGravity
}

And here is the original Java code.

public enum Planet {
    MERCURY (3.303e+23, 2.4397e6),
    VENUS   (4.869e+24, 6.0518e6),
    EARTH   (5.976e+24, 6.37814e6),
    MARS    (6.421e+23, 3.3972e6),
    JUPITER (1.9e+27,   7.1492e7),
    SATURN  (5.688e+26, 6.0268e7),
    URANUS  (8.686e+25, 2.5559e7),
    NEPTUNE (1.024e+26, 2.4746e7),
    PLUTO   (1.27e+22,  1.137e6);

    private final double mass;   // in kilograms
    private final double radius; // in meters
    Planet(double mass, double radius) {
        this.mass = mass;
        this.radius = radius;
    }
    public double mass()   { return mass; }
    public double radius() { return radius; }

    // universal gravitational constant  (m3 kg-1 s-2)
    public static final double G = 6.67300E-11;

    public double surfaceGravity() {
        return G * mass / (radius * radius);
    }
    public double surfaceWeight(double otherMass) {
        return otherMass * surfaceGravity();
    }
}

The Scala code is nicer, though its unfortunate that you have to say "extends Planet" for each Planet. Each planet is defined as a Scala "object" which is really nothing more than a singleton, which is what enum values are in Java.

I could and should go into more detail on all of this, but I'm mostly posting it for my own reference.

When To Call a Constructor Part 1

I've it said before (and people a lot smarter than me like Gilad Bracha), and I'll say it again: Constructors are Evil. Unfortunately, in most common situations, they are impossible to avoid. Rather than beating a dead horse, I'm going to take a slightly different approach. In this post I'll focus on when it is ok to call a constructor, and how to do so effectively. This information can be applied to any number of OO languages.

(Note: It is of course sometimes possible to get away from calling constructors by using a DIF like Guice. Sometimes its just not possible. For example, you have a legacy code base that you are maintaining/extending. It may be possible to switch it over to a DIF, but its unlikely to happen all at once and you probably don't want to end up with a code base that is somewhere halfway between. That can make code even more difficult to reason about. Regardless, even if you are using a DIF you still want to call new sometimes, which I'll explain later.)

I'll start with a simple example.

public class PersonCache {

  private final Map<Name, Person> storage;
  
  public PersonCache(){
    storage = new HashMap<Name, Person>();
  }
  
  public void addPerson(Person p){
    storage.put(p.getName(), p);
  }

  public Person getPerson(Name name) {
    return storage.get(name);
  }
  
  public void removePerson(Person p){
    storage.remove(p.getName());
  }
}

This class looks reasonable, and in fact it is. But as you'll see later, simple classes like this lull developers into a false sense of security with the "new" statement. Here, calling new on HashMap is ok because:

1. It is a trusted/tested class
2. It has no significant dependencies
1. It doesn't reference any static state
2. It doesn't do any IO

Theres a bit of a theme here. If you are going to call a constructor, you need to have a solid understanding of the class you're instantiating. Because it's so well documented, we know HashMap is safe to instantiate. Unfortunately, most code isn't so well documented. Most developers don't understand each class they instantiate.

So why isn't it ok to instantiate an unknown, untrusted class, or a class with dependencies?

To answer that lets first briefly look at the design forces. There are at least four (and probably more) design forces at play here.

• Encapsulation
• Readability
• Static Dependencies
• Testability

The forces certainly push and pull on each other a bit. As encapsulation goes up so do readability and static dependencies, while and testability goes down. While we can't always have the best of each, it's important to understand when to choose one over the other.

Consider the following example.

public class PersonCacheWithDatabase {

  private final Database storage;
  
  public PersonCacheWithDatabase(){
    storage = new Database();
  }
  
  public void addPerson(Person p){
    storage.put(p.getName(), p);
  }

  public Person getPerson(Name name) {
    return storage.get(name);
  }
  
  public void removePerson(Person p){
    storage.remove(p.getName());
  }  
}

This certainly doesn't look a whole lot different than the first example. But, its infinitely worse. Doubly do because it cleverly tricks you into thinking that its ok by looking so similar.

First, DatabasePersonCache may appear to be encapsulated, but in reality its not. It forces you to know about the database whether you like it or not. If you're going to call this constructor, you had better have a database set up somewhere. Otherwise, try to use it and you're going to get exceptions left and right. For the exact same reason, its difficult to read and test this code. Reading it alone is simply not enough. You need to understand the database class as well. Additionally, this class is forever statically bound to the Database class. If you somehow want to store your people in a more convenient way, well, you just can't. If you want to test a class that uses PersonCache, good luck.

There is a way around this - pass in a StorageStrategy into PersonCache.

public interface StorageStrategy {

  public void put(Name name, Person p);
 
  public Person get(Name name);
 
  public void remove(Name name);
}


public class PersonCacheWithStorageStrategy {

  private final StorageStrategy storage;
  
  public PersonCacheWithStorageStrategy(StorageStrategy storage){
    this.storage = storage;
  }
  
  public void addPerson(Person p){
    storage.put(p.getName(), p);
  }

  public Person getPerson(Name name) {
    return storage.get(name);
  }
  
  public void removePerson(Person p){
    storage.remove(p.getName());
  }
}

PersonCacheWithStorageStrategy is much better than the PersonCacheWithDatabase. As long as StorageStrategy is an interface, PersonCache is now nice and reusable, it can be used with a HashMap, a Database, anything. It isn't statically bound to any implementation. It's definitely more readable as you are safe assume that the StorageStrategy passed in works fine. It's far more testable on the whole - you don't have to set up a database to test it.

However, even though its better than the second example, it does suffer problems that the original PersonCacheWithHashMap does not suffer - poor encapsulation. You have to know something about StorageStrategy in order to use it. What if you only ever want to use this as a quick in-memory helper object? The first example would be far better. What if you only ever needed the in-memory storage capability while using PersonCache? A client is still forced to create a StorageStrategy. Ick.

This is the point where it would be really nice to have a forth example and say this is how to do it. Unfortunately there isn't one magic scenario that solves every problem. Developers need to understand the design forces and the code objects they are clients of in order to make reasonable decisions about their code. If its not entirely safe to call new, based on the rules above, then you must pass your dependencies in. You trade some encapsulation for another design force: sanity.

Now, you may be thinking, well great, in the example 3 you just deflected the problem of calling new upward, but that doesn't help me much, since I still have to call new in the clients of PersonCache. You would be correct. I haven't addressed that issue just yet. But for that you'll have to stay tuned for part two of this mini series.

My First Scala Presentation

I gave my first talk on Scala today, to my team at NYSE. It was an entirely informal, BYOL (Bring your own lunch) talk that I hadn't prepared for at all (I was hoping someone else would speak, but since no one else ever does, its always me, prepared or not). Anyway, there are some lessons learned from the talk.

The talk didn't really go over that well, and mostly because I didn't hit them hard with a great example up front. Next time I will. I finally won them over when I showed a List example, which I'll show here.

Say you want to create a List of integers containing the elements 1, 2, and 3. In Java there are a few ways to go about it, none of them very easy. I'll start with the most common example.

List<Integer> ints = new ArrayList<Integer>();
ints.add(1);
ints.add(2);
ints.add(3);

Like I said, there may be easier ways to do this, but I don't think many people will argue that this would be by far the most commonly used approach. There are several things wrong with it.

• It's about a billion characters long.
• The redundant type information in the first line is so frustrating.
  
• The next three lines of code are almost identical.
• The semi colons are pretty much pointless.
  

Here's how you do the same thing in Scala.

val ints = List(1,2,3)

Thats it.

• Its 20 characters total (not including the unneeded spaces). 20 characters vs. A Billion! I pick 20.
• There is no need whatsoever to put an absurd amount of type information. The compiler is perfectly capable of figuring that out thank you. As are humans; any second year college student could tell that thats a list of integers. Heck, any 7 year old could too.
• There is absolutely no redundant code here.
  
• There are no semi colons.

This example has probably been posted on the internet about a million times by now, and its not the point of this post. The point is this: If you want to give a talk on a language, hit the audience hard with a solid example immediately. Don't dilly-dally and give examples that are only slightly different than their current language and then give them the good stuff. You'll meet too much opposition up front. I thought I was doing them a favor by easing them into Scala but what really happened was quite the opposite. For some terrible reason Java developers are quite territorial. I was providing fuel for them to say, "I'll stick with Java."

Next time, I give the good example up front, then transition to the easy stuff once I've peaked their interest, and then make sure to finish up with a solid example too. And of course next time I'll be quite a bit more prepared.


Ok. Thats the gist of what I was wanting to talk about, now some sideline commentary.

One particularly odd complaint IMO was that most of this was just syntactic sugar. First off, I whole-heartedly disagree, but I can see why some people could incorrectly think that way. My colleague happily responded:

If you think it's just syntactic sugar, then I have a perfect language for you. It only contains 2 characters, 1, and 0. Using anything else, well thats just syntactic sugar.

Of course anyone can think that higher level languages are just prettier syntax, but they would be entirely missing the point. The point is to not have our primitive human minds bombarded with useless information so that we can better and more easily understand the meaning of each line of code. Thats not sugar, thats evolution, baby.

ScalaTest and TestNG

THIS IS AN INCOMPLETE DRAFT, POSTED FOR REVIEW. I UNDERSTAND SOME SECTIONS NEED WORK AND SOME SECTIONS ARE EMPTY OR MISSING ENTIRELY, AND THAT THE FORMAT MIGHT BE MESSED UP.

ScalaTest has two important goals.

1. Allow tests to be written in Scala easily, and concisely.
   
2. Allow Java developers to transition to ScalaTest with minimal effort.

With these two goals in mind I'm happy to announce ScalaTest's integration with TestNG. This integration offers two features that meet the goals of ScalaTest.

1. TestNG tests can be written in Scala, and run in both ScalaTest and TestNG runners.
   
2. Existing TestNG tests can be run in ScalaTest.

By being able to write new TestNG tests in Scala, a developer doesn't have the overhead of learning a new test framework and a new language at once. And more importantly, by being able to run existing test suites in ScalaTest developers can feel confident that all their code is working without the overhead of running two test frameworks at once.

This article will show you how to use ScalaTest to do both, with the help of an example (available for download from the ScalaTest Subversion repository). The example has been tested against Scala 2.7.0, and TestNG 5.7. To use the example you'll also need to download the latest version of ScalaTest.

After downloading everything, you'll need to place the jars into the lib directories of the example. Place the TestNG jar into the java/lib, and place the Scala related jars into the scala/lib folder. You should end up with the following directory structure (as shown here in Eclipse).

About the Example

The example contains what we'll refer to as "existing" code (Java), and "new" code (Scala). The thinking here is that you are working on an existing project in Java, you have a Java code base complete with unit tests (you do have unit tests, don't you?), and that you're interested in exploring Scala. If you're Java code isn't covered with tests the content here is still relevant; you can learn how to write TestNG tests in Scala.

The existing code lives in the java folder where you'll find:

• VolumeKnob.java - An interface for volume knobs
• BoringVolumeKnob.java - A boring implementation of VolumeKnob
• BoringVolumeKnobTest.java - A boring test for BoringVolumeKnob
• volume-tests.xml - A TestNG XML suite to run BoringVolumeKnobTest
• build.xml - Ant file that builds the code and runs the tests
  

The new code is in the scala folder, and it builds upon the existing Java code. In the scala folder you'll find:

• AwesomeVolumeKnob.java - A totally awesome implementation of VolumeKnob
• AwesomeVolumeKnobTest.java - An awesome test for AwesomeVolumeKnob
• build.xml - Ant file that builds the code and has targets to
  
• Run just the existing Java tests in ScalaTest
  
• Run just the Scala tests in ScalaTest
• Run both the Java and Scala tests in ScalaTest
  

Quick Look At What Needs To Be Tested

In the next section we're going to learn how to write TestNG tests in ScalaTest. But before we do, lets take a quick look at what we're going to test. Recall in the java folder the interface VolumeKnob. It's very simple:

public interface VolumeKnob {
    public abstract int currentVolume();
    public abstract int maxVolume();
    public abstract void turnUp();
    public abstract void turnDown();
}

VolumeKnob has two implementations that need testing. The first is a rather boring Java implementation - BoringVolumeKnob. It's too boring to show here, and it can't be turned up beyond 10. It has a corresponding TestNG test class also written in Java - BoringVolumeKnobTest. That won't be shown here either, since we'll assume you know TestNG.

There is also a Scala implementation of that interface, AwesomeVolumeKnob. AwesomeVolumeKnob's have three amazing qualities:

• They always go to at least 11 (of course)
• They can never be turned down
• They can always be turned up, regardless of the max volume.

import org.scalatest.legacy.VolumeKnob

class AwesomeVolumeKnob( val maxVolume: int ) extends VolumeKnob {
  if( maxVolume < 11 ) 
    throw new IllegalArgumentException("...These go to eleven.");
  
  var currentVolume = maxVolume;
  
  def turnDown = 
    throw new IllegalAccessError("AwesomeVolumeKnobs cannot be turned down");
  
  // AwesomeVolumeKnobs don't care about max volume
  def turnUp = currentVolume = currentVolume + 1;
}

AwesomeVolumeKnob is accompanied by AwesomeVolumeKnobTest, which is a TestNG test written in Scala. We'll cover that next.

Writing TestNG tests in ScalaTest

Because Scala allows you to use Java's annotations, TestNG tests can be written in Scala at least as easily as they can in Java. Here is a quick example:

import org.scalatest.legacy.VolumeKnob

class AwesomeVolumeKnobTest{
  @Test
  def awesomeVolumeKnobsCanBeTurnedUpReallyHigh(){
    val v = new AwesomeVolumeKnob(10000)
    for( i <- 1 to 1000 ) v.turnUp
  }
}

There's really nothing to it. This class can be compiled by the Scala compiler and run in any TestNG runner.

To enable your test to be run in ScalaTest, simply extend the ScalaTest trait org.scalatest.testng.TestNGSuite. That's it. Here is the full implementation of AwesomeVolumeKnobTest in all its glory.

import org.scalatest.testng.TestNGSuite
import org.testng.annotations._

class AwesomeVolumeKnobTest extends TestNGSuite{

  @Test{ val description=
         "create AVK's with max volume < 11 and ensure IllegalArg is thrown" 
         val dataProvider="low volumes", 
         val expectedExceptions = Array( classOf[IllegalArgumentException] )}
  def awesomeVolumeKnobsAlwaysGoToAtLeastEleven(maxVolume: int){
    new AwesomeVolumeKnob(maxVolume);  
  }  
  
  @Test{ val description=
         "try to turn down some AVK's and ensure IllegalAccess is thrown"
         val dataProvider="high volumes", 
         val expectedExceptions = Array( classOf[IllegalAccessError] )}
  def awesomeVolumeKnobsCanNeverBeTurnedDown(maxVolume: int){
    new AwesomeVolumeKnob(maxVolume).turnDown();
  } 
  
  @Test{ val description="crank it up" }
  def awesomeVolumeKnobsCanBeTurnedUpReallyHigh(){
    val v = new AwesomeVolumeKnob(10000)
    for( i <- 1 to 1000 ) v.turnUp
  }
  
  @DataProvider{val name="high volumes"}
  def goodVolumes = 
    Array(v(11), v(20),v(30),v(40),v(50),v(60),v(70),v(80),v(90),v(100))
  
  @DataProvider{val name="low volumes"}
  def lowVolumes = 
    Array(v(1), v(2),v(3),v(4),v(5),v(6),v(7),v(8),v(9),v(10))
  
  def v( i: Integer ) = Array(i)
}

There are a few things to notice with this implementation.

Running Scala TestNG Tests in ScalaTest

Running TestNGSuite's in ScalaTest is no different than running any other ScalaTest Suite - simply use the Ant task. In scala/build.xml in the example, you'll find a target called "test-scala-only":

 <target name="test-scala-only" depends="compile">
  <taskdef name="scalatest" classname="org.scalatest.tools.ScalaTestTask" 
   classpathref="test.classpath"/>
  
  <scalatest>
   <runpath>
    <pathelement path="test.classpath"/>
    <pathelement location="${test.jar.file}"/>
   </runpath>
   
   <suite classname="org.scalatest.testng.AwesomeVolumeKnobTest"/>
   
   <reporter type="stdout" />
   <reporter type="graphic" />
   
  </scalatest>
 </target>

In this case we have just one Suite to run:

<suite classname="org.scalatest.testng.AwesomeVolumeKnobTest"/>

Running this task brings up the ScalaTest UI:

Running the Java Tests

If you're a TestNG user, you're likely to be familiar with running test suites from the IDE. There are a couple of different ways to do it, and whichever you choose, you're sure to end up like something like this (as shown in Eclipse):

While this is great, and familiar, and comfortable, it would be a pain to have to run your Java tests through TestNG's UI and then have to switch over to ScalaTests UI to run your Scala tests.

Running Java Tests in ScalaTest

ScalaTest provides a simple way to run TestNG xml suites in its Ant task. In scala/build.xml in the example, you'll find a target called "test-java-only":

 <target name="test-java-only" depends="compile">
  <taskdef name="scalatest" classname="org.scalatest.tools.ScalaTestTask" 
   classpathref="test.classpath"/>
  
  <scalatest>
   <runpath>
    <pathelement path="test.classpath"/>
    <pathelement location="${test.jar.file}"/>
   </runpath>
   
   <testNGSuites>
    <pathelement location="${java.dir}/src/test/volume-tests.xml"/>
   </testNGSuites>
   
   <reporter type="stdout" />
   <reporter type="graphic" />
   
  </scalatest>
 </target>

Inside the testNGSuites block, simply put the location of the xml suite.

  <testNGSuites>
    <pathelement location="${java.dir}/src/test/volume-tests.xml"/>
  </testNGSuites>

While in this case there's one xml suite only, ScalaTest supports multiple xml suites. All suites get run in the same TestNG instance. Running ScalaTest via Ant with the graphic reporter option brings up the ScalaTest UI:

As you can see, ScalaTest reported the exact same results as the TestNG Eclipse plugin. (But...notice that our green bar is much brighter!)

Running All The Tests Together

Finally, for the moment of truth...though being so easy, it's likely a bit of a letdown. To run all the tests together, simply use both options in the Ant task, as in the "test" target in scala/build.xml.

 <target name="test-java-only" depends="compile">
  <taskdef name="scalatest" classname="org.scalatest.tools.ScalaTestTask" 
   classpathref="test.classpath"/>
  
  <scalatest>
   <runpath>
    <pathelement path="test.classpath"/>
    <pathelement location="${test.jar.file}"/>
   </runpath>
   
   <suite classname="org.scalatest.testng.AwesomeVolumeKnobTest"/>

   <testNGSuites>
    <pathelement location="${java.dir}/src/test/volume-tests.xml"/>
   </testNGSuites>
   
   <reporter type="stdout" />
   <reporter type="graphic" />
   
  </scalatest>
 </target>

Running this task brings up the ScalaTest UI:

Problems

Summary

ScalaTest and Mocking

I've added in some mocking into ScalaTest thanks to specs integration. I've done it in a BDD style, kind of like rspec's given/when/then. rspec is much further along and I still need to learn a lot more about it, but thats okay. I'm hoping just to get some peoples opinions on readability and such. Here are a couple very quick examples.

 mockTest( "Report should be generated for each invocation" ){
       
   val reporter = mock(classOf[Reporter])

   expecting( "reporter gets 10 passing reports because invocationCount=10" ) {
     nTestsToPass( 10, reporter )
   }

   when ( "run the suite with method that has invocationCount=10" ){
     new TestNGSuiteWithInvocationCount().runTestNG(reporter)
   }
 }
     
 mockTest( "Reporter should be notified when test is skipped" ){
       
   val reporter = mock(classOf[Reporter])

   expecting ( "a single test should fail, followed by a single test being skipped" ){ 
     one(reporter).runStarting(0) 
     one(reporter).testStarting(any(classOf[Report])) 
     one(reporter).testFailed(any(classOf[Report])) 
     one(reporter).testIgnored(any(classOf[Report]))
     one(reporter).runCompleted()
   }

   when ( "run the suite with a test that should fail and a test that should be skipped" ){
     new SuiteWithSkippedTest().runTestNG(reporter)
   }
 }

As you can see, I've added expecting and when blocks, which optionally take a String (that is currently just used for readability). The simple idea here is that I have grouped chunks of my test into places that make sense, hopefully making it easier for someone reading the test. Do you like it? Do you hate it? Any other opinions that could help?

Which Style Is More Readable?

I've been writing ScalaTest tests for the ScalaTest TestNG integration (say that five times fast). I used a couple of different styles and I was hoping to get some input on which style people thought was more readable, more clear. Both styles are functional, one merely masks it a bit while the other flaunts it.

The first style I'll show is the discrete style. Here I call a test method which takes a function and executes it.

     test( "Reporter Should Be Notified When Test Passes" ){
    
       val testReporter = new TestReporter

       // when
       new SuccessTestNGSuite().runTestNG(testReporter)

       // then
       assert( testReporter.successCount === 1 )
     }
  

     test( "Reporter Should Be Notified When Test Fails" ){
    
       val testReporter = new TestReporter

       // when
       new FailureTestNGSuite().runTestNG(testReporter)

       // then
       assert( testReporter.failureCount === 1 )
     }

The I'm showing only two examples of calling the test function but in actuality I have many more tests. Notice that in each test the first line is always the same:

       val testReporter = new TestReporter

There are benefits to this. All the code is right there and you can read the test method without looking anywhere else. There are also some negatives as well. I have the same line of code in several places.

Now I'll show the even more functional style. It takes a little more explaining. Here I declare a withFixture method that accepts a function that takes a TestReporter as its input. The withFixture method creates the TestReporter (so each test call doesn't have to) and calls the input function passing it the TestReporter. To create tests I call the testWithFixture function which takes a function and passes it to the withFixture function I just wrote.

     override def withFixture(f: (TestReporter) => Unit): Unit = {
       f(new TestReporter) 
     }
     
     
     testWithFixture( "Reporter Should Be Notified When Test Passes" ){ 
       t: TestReporter =>

       // when
       new SuccessTestNGSuite().runTestNG(t)
       // then
       assertThat( t.successCount, is(1) )
     }
  

     testWithFixture( "Reporter Should Be Notified When Test Fails" ){ 
       t: TestReporter =>

       // when
       new FailureTestNGSuite().runTestNG(t)
       // then
       assert( t.failureCount === 1 )
     }

I'm realizing as I'm writing this that all the extra explaining I had to do is because the code is more complicated. There are definite negatives here. Code is being passed around to other code, you might now be sure how things are actually running, you might not be sure where the TestReporter object is coming from. On the upside the methods are slightly shorter and I've removed the most obvious duplication by moving it to the withFixture function. There's still plenty of duplication (in each example) that could be removed but you can definitely push duplication removal too far. Especially in tests, you must balance duplication and indirection. They are in direct opposition.

Does this code push it too far?

Is this just a setup method in disguise? I'm of the opinion that setup methods are bad, but at least here everything is immutable.

If people were to get used to this style would it become more readable in the long run?

Please please let me know your thoughts.

Scala and TestNG in Far Greater Detail

I wrote before on running TestNG in Scala and due to popular demand I'm going to go into much greater detail. My goal is to show that running TestNG in Scala is as easy as it is in Java. I've thrown in Hamcrest to show that that integrates seamlessly as well. Hopefully along the way you'll learn a couple of Scala nuggets too. And, be warned I'm assuming you know a bit about TestNG so I'm not going to explain it much. If you don't...www.testng.org

I created a new Scala class for testing my AndGate class. The idea is that I want to make sure that my AndGate is on or off according to the standard And boolean logic table:

x y | output
------------
0 0 |   0
0 1 |   0
1 0 |   0
1 1 |   1

The testing class is called ScalaTestNGExampleTest, and it looks like this:

import org.testng.annotations._
import org.hamcrest.MatcherAssert._
import org.hamcrest.Matchers._;
import org.testng.annotations.DataProvider;
import com.joshcough.cpu.gates._

class ScalaTestNGExample {
  
  @DataProvider{val name="generators"}
  def createGenerators = { 
    val gens = Array(off, on)
    for( x <- gens; y <- gens ) yield Array(x,y)
  }
  
  private def on = new Generator(true)
  private def off = new Generator(false)
 
 
  @Test{ val dataProvider="generators" }
  def testAndGateStates(genA: Generator, genB: Generator){
    val and: AndGate = new AndGate(genA, genB);
    val whatItShouldBe = genA.on && genB.on
    assertThat( and.on, is(whatItShouldBe) );
    println( and.on + "==" + genA.on + "&&" + genB.on )
  }  
  
  @BeforeMethod def printLineBefore = println("------entering test------")
  @AfterMethod  def printLineAfter  = println("------exiting  test------")
  
}

If you aren't familiar with Scala that might look a bit like magic, so I'll explain one step at a time.

Data Provider

The first thing I did was set up a data provider for my logic table:

1. The annotation declaration is obviously different than in Java. Instead of parentheses, you have to use curly brackets. Instead of simply name/value pairs, you have to declare vars. I could explain why, but instead you could just go to http://www.scala-lang.org/intro/annotations.html.
   
   
2. DataProvider methods are supposed to return Object[][], but...what the heck is this one returning? Well, before I explain what that funky for statement is actually doing I'll just announce that this method is actually returning Array[Array[Generator]]. I could have made it more explicit by saying def createGenerators(): Array[Array[Generator]] but Scala's type inference lets me get away with leaving it off. Does leaving it off hamper readability? In most leaving it off is just eliminating some redundancy. Maybe in this case I should have left it on, but I wanted to show type inference a little bit.
   
   
3. Wait a second...Array[Array[Generator]] isn't Object[][]...or is it? Actually, yes. Scala's typed array class (Array[T]) actually compiles down to Java arrays. In this case, Array[Array[Generator]] compiles down to Generator[][] in Java.
   
   
4. What is Array(on, off)? The type of Array(on, off) is Array[Generator] and it contains two elements, Generator(true) and Generator(false) which are returned from the on and off methods respectively. It may be confusing for a Java programmer to see simply "on" with no parens. In most cases (for reasons far beyond the scope of this post) Scala doesn't force you to use parens on method calls with no arguments.
   
   
5. Ok finally, what is that funky for loop looking thing doing? Rather than explain, why don't I just give the equivalent code in Java for the createGenerators method?

public Generator[][] createGenerators() {

Generator[] onAndOff = new Generator[]{ on(), off() };

Generator[][] gensToReturn = new Generator[4][2];
for( int i = 0; i<onAndOff.length; i++ ){
for( int j = 0; i<onAndOff.length; j++ ){
 gensToReturn[i+j] = new Generator[]{ onAndOff[i], onAndOff[j] };
}
}
return gensToReturn;
}

Honestly? Those three lines of code are doing all of that...? Yes. Honestly. Rather than me trying to explain it though, James Iry does an excellent job in part 2 of his four part series on monads called Monads are Elephants. That is the link to part two, but I recommend reading all four.

So now we have a data provider and we have a reasonable idea how it works. But quickly before I move on, heres another way I could have done it which is arguably more readable but not nearly as much fun. Once again, the idea here is that this data provider is essentially creating the And logic table for us.

def createGenerators = {
Array(Array(on, on),Array(on, off),Array(off, on),Array(off, off))
}

Test Method

At this point I think everything else is really straight forward. Despite that, I'll go over the test method in detail.

1. The @Test annotation is defined in the same fashion as I described above for @DataProvider. In this case I define which data provider to use. Done.
   


2. The method takes two Generator parameters which come from createGenerators method.
   


3. The first line simply instantiates an AndGate object using the two Generator parameters.
   


4. The second and third lines simply assert that the AndGate is what it should be! It should be on only when both generators are on, according to the logic table. The third line uses Hamcrest matchers for asserting. I'm not going to bother explaining them here.
   


5. Finally I throw in a print statement.
   

BeforeMethod And AfterMethod Annotations

Before each test method is called, TestNG will call any methods annotated with @BeforeMethod. In my case before each method I just print a nice message. The same goes for @AfterMethod, but after each test method, of course.

Results

Here is my output from the console:

 [testng] -----------entering test-----------
 [testng] true==true&&true
 [testng] -----------exiting  test-----------
 [testng] -----------entering test-----------
 [testng] false==true&&false
 [testng] -----------exiting  test-----------
 [testng] -----------entering test-----------
 [testng] false==false&&true
 [testng] -----------exiting  test-----------
 [testng] -----------entering test-----------
 [testng] false==false&&false
 [testng] -----------exiting  test-----------

Problems

I did run into a few problems.

1. FIXED: Unfortunately, I couldn't use @Test{expectedExceptions = {SomeException.class}} because Scala doesn't you say Anything.class.
2. Running the tests through Eclipse is not as easy as it is in Java, and needs some work. I ended up mostly running through Ant, but sometimes through Eclipse.

Conclusion

I hope I've convinced you that running TestNG in Scala is simple. I didn't test all the features, but most of what I have tested works great. I plan to use it for most of my Scala development. I personally think its pretty far ahead of the pack, but if you want to see for yourself they are: ScalaTest, ScUnit, Rehersal, JUnit, and specs. I've tried the last four, and of those I thought specs was really nice. It seems like a reasonable alternative.

I am very open to hear ideas on why I should switch to an xUnit test framework built in Scala. Are there any advantages? What are they?

My Small Problem with the Scala Actor Model

Something seems wrong to with the whole send/! idea. The Scala guys say ! apparently means "send", but it really means "add message to actors mailbox", or "put". Take this example:

actor ! message
actor send message

If ! means "send", then it certainly seems like the actor is sending the message. Of course, you have no idea who its sending it to, so by that logic it must be getting the message, but it still just seems confusing. I think the API might be more readable if it used one of the following:

actor <-- message
message --> actor

I've demonstrated that you can use --> and <-- as method names already, so, why not use them here?

Scala: Fold Left Question

I recently realized that I could make a piece of code I posted in a recent blog much cleaner using foldLeft. I have a bit of a problem however, the code is in a very performance sensitive area and I should break out of the fold whenever I encounter a certain condition. To the best of my knowledge foldLeft has no way to break out. It just folds all the way and you get your result at the finish. This is a bit unfortunate. Is there a way to break out and still keep the code clean?

Here is my example, old code first. A PowerSource is on if any of its incoming power sources are on.

 private def updateOnOff = {
   def calculateOnOff: boolean = {
     incomingPowerSources.foreach( p => {if( p.isOn ) return true; })
     return false;
   }
   val newOnOff = calculateOnOff
   if( cachedOnOffBoolean != newOnOff ){
     cachedOnOffBoolean = newOnOff
     notifyConnections;
   }
 }

Here is the new code using foldLeft.

  private def updateOnOff = {
    val newOnOff = incomingPowerSources.foldLeft( false )(_||_.isOn);
    if( cachedOnOffBoolean != newOnOff ){
      cachedOnOffBoolean = newOnOff
      notifyConnections;
    }
  }

The new code is far nicer than the old code. I've decided I'm going to go with it. In most cases PowerSources have only one direct input. Some have two, like OrGate, but for now I'm going to see what kind of performance hit I get.

Now, if only I had a performance testing framework in Scala. Does anyone know of one?

Closures Non Local Return - Scala And Java

I've heard a lot of people bickering about Java Closures. One of the many reasons they are fighting with each other is that in the BGGA proposal changes the semantics of return. In BGGA there can be local and non local returns (I'll explain those in a second). Bloch says it going to be too prone to bugs. Gafter says we need to do it before the language becomes a dinosaur. I tend to go with Neal on this one, maybe thats because I'm more adventurous and not quite as worried about bugs since I do extensive unit testing.

Anyway, I wanted to demonstrate the problem in Scala. It did bite me today a little bit. I caught it quickly in my tests. The following two bits of code have different meanings:

private def updateOnOff = {
 def calculateOnOff: boolean = {
   incomingPowerSources.foreach( p => {if( p.isOn ) true; })
   return false;
 }
 cachedOnOffBoolean = calculateOnOff;
}

private def updateOnOff = {
 def calculateOnOff: boolean = {
   incomingPowerSources.foreach( p => {if( p.isOn ) return true; })
   return false;
 }
 cachedOnOffBoolean = calculateOnOff;
}

The purpose of the updateOnOff function is to simply set the cachedOnOffBoolean to true if any incoming power sources are on. If none of them are on, the boolean is set to false. The inner function, calculateOnOff is responsible for looping through the incoming power sources to see if any are on. If one is on the function should return true to the outer function which sets the boolean.

To be honest, I'm not sure which one is the local and which one isn't. I'm in the process of trying to figure it out. It seems natural to me though to assume that the first one is the local return. If anyone knows better, please let me know.

The first example is an example of local return. Local return returns from the most local block of code, and in this case its the closure function itself, not the calculateOnOff function. The closure here is what's inside the foreach call:

( p => {if( p.isOn ) true; } )


This is the function that will be returned from. It simply returns back to the loop, which goes on to the next item. Finally, when the loop is finshed, false is returned. So, in the first example false will always be returned! This is certainly not correct.

The second example is and example of non local return. Specifying "return" before false means that you intend to return from the enclosing method, not just the closure itself. You intend to break out of the loop. You've found what you were looking for, and you were done. The return returns true from the calculateOnOff, and the boolean is set to true, just as you wanted.


Its pretty straight forward when you know it but I'm sure Bloch is right, there are going to be lots of bugs. Developers who don't use unit testing religiously are going to get it. A simply copy past from a refactoring, and boom.

So what does this tell us? Well, at the least it says be careful, and write lots of unit tests. At the most it might mean that lots of idiots just stay in Java and the cool kids move on to Scala, and thats all right now baby, yeah.

Coolest Code I've Ever Written

Because Scala lets you name methods pretty much whatever you want, I got the chain wires together like this:

 @Test
 def lastPowerSourceInChainShouldBeNotifiedWhenFirstInChainIsTurnedOff() = {
   //given
   val first = new Generator
   val secondToLast = new Wire
  
   first-->new Wire-->new Wire-->new Wire-->secondToLast
  
   val last = createMockWithConnectionTo(secondToLast)
  
   // when
   first.turnOff
  
   // then
   verify(Array(last))
 }

 private def createMockWithConnectionTo( p: PowerSource ): PowerSource = {
   val mockPowerSource: PowerSource = createStrictMock(classOf[PowerSource]).asInstanceOf[PowerSource];
   expect( mockPowerSource <-- p ).andReturn( p )     expect( mockPowerSource.handleStateChanged( p ) )     replay(Array(mockPowerSource))     p --> mockPowerSource
   mockPowerSource
 }

The -->'s are actually methods on any PowerSource that connects the two together. So, the code can actually look like a chain of wires connected together. This is totally the coolest thing ever.

Using TestNG in Scala: By Example

Here is a very, very simple example of some TestNG stuff that I wrote the other day in Scala (it can also be found here):

package com.joshcough.cpu.electric;

import org.testng.annotations._
import org.testng.Assert_

package com.joshcough.cpu.electric;

import org.testng.annotations._
import org.testng.Assert._

class GeneratorTest {

  @Test
  def expectNewGeneratorToBeOn() = {
     val gen: Generator = new Generator
        assertTrue(gen.isOn);
    }
  
  @Test
  def expectTurnedOffGeneratorIsOff() = {
        val gen: Generator = new Generator
        gen.turnOff
        assertTrue(gen.isOff);
    }  
}

This might not be the prettiest code in the world, but:

• It works (which is more than I could accomplish with others)
• I can run it in my IDE
• I can run it in Ant
• I only have to do exactly what I ever did with Java
• Its still way better than JUnit

There were a few things I had to do to make this work:

• When compiling in Ant, I had to add this to my scalac call:
  
• target="jvm-1.5" ...
• When compiling in Eclipse I had to do this:
• Project -> Properties -> Scala Compiler Properties -> target = jvm-1.5

I could give a more detailed example, but I haven't tried it yet. I'm pretty sure that things like @BeforeMethod, @AfterClass, @DataProvider and what not all just work the same. I'll try to come up with a better example though.

Reading Scala

After working a bunch in Scala the other day, and continuing to obsess over it, I've realized something.

Reading the code Scala language source code is perfect code reading material.

I had said that I needed some good code to read. Scala is perfect for this. Here are the reasons its good for me.

• It's really good code
• Its easy to read (I guess these two go together nomally)
  
• It has a really nice mix of OO and Functional Programming (which I need to get better at anyway)
  
• Its got a compiler written in Scala compiling to Java bytecode. :)
  
• Its a langauge for god sakes, and I want to do language design so I should look at more language implementations

But, are those the same reasons its good for someone else to read? Maybe not, but I think Scala is still great for other people to read, beginners, professionals, and Ph.d's alike.

• The first two points hold true: Its really good code, and its easy to read.
• Beginners could easily read the data structures code in Scala collections. They could learn their data structures, learn FP, and learn OOP better all at once.
• Theres a wealth of stuff for more advanced people to read.
  
• The Actor Model for instance, which is Scalas concurrency stuff built on top of Doug Lea's fork join.
  
• Langauge Designers could read it and learn a bit.
• Compiler writers could read it and learn a bit.
• Software Engineers could read it, and read the examples to learn a few things:
• How to do things better in their own language
• What they are missing stuck in an ancient language.
  

As I said before, It's probably helpful to read java.util.concurrent and the java collections stuff, and I'm sure theres a whole lot of other code thats great to read too. But, I'm getting worn out when it comes to Java. I'm ready to move on. Scala is new and fresh and exciting, and, I'll learn more by doing it.

Unit Testing in Scala and in IDE's in General

I reviewed a few Scala unit testing frameworks today: SCUnit, and Rehersal. When all was said and done I determined something that I found rather remarkable - TestNG is the best unit testing framework for Scala. For an example click here. To listen to my mind numbing justification of that radical statement, read on...

Why aren't new Unit Testing frameworks up to snuff?

The problem with any new unit testing framework in a new language is that it doesn't have IDE support. This is a huge pain in the ass for someone who relies on their IDE for everything (like me). TestNG already has IDE support, and you can use Java Annotations in Scala, so you can use TestNG just fine in Scala as well.

Does that mean the test frameworks themselves are bad? No, they are fine. But to be entirely honest, its probably not all that worthwhile for someone to build a xUnit framework in Scala other than the fact that its probably really fun. And I say all this knowing full well that could be horse shit - I don't enough about Scala. There may be some nice syntactic stuff that makes testing in Scala just better, more readable, easier to write - I'm not sure. Its my gut feeling. Anyway...

There is still a fundamental underlying problem here.

The main problem with this whole thing is (well there actually might be a couple, but one at a time) that if you want to write an xUnit framework for a language you have write the IDE support for it too. You shouldn't have to do this.

So what can we do to fix this?

IDE's should provide xUnit framework plugin points. All you have to do is plug in your particular framework, and boom instant IDE suppport for your xUnit framework. I've been saying this for a while about languages themselves. All you need to do is plug-in the compiler and boom, you have everything. Maybe thats too much to bite off...but I don't think plugging in your own xUnit is.

The JUnit and TestNG Eclipse plug-ins are nearly identical. They both look damn near the same as the test runner for NUnit. The patterns are clearly obvious. I haven't looked at the implementations at all, so I don't yet have any concrete ideas on how to make this happen, but its so worth it. Someone should do it. It could be me.

Finally...

This could be the first step towards instant IDE support for new languages. Maybe we identify several areas like this that are similar across languages and provide plug-in points for each. What would those features be? I'm not sure I still need to think. And, maybe more languages should just use the support of Java like Scala does.

But, I have to say this was a great day. In my opinion realizing this was a real breakthrough in what I know about well, everything. Additionally, I think I am finally saying things that I haven't really heard other people saying. Maybe they are and I haven't read it, but I feel like I might actually be making some progress.

Things are coming together (and Scala is awesome)

I did a ton of reading on Scala today, and I did a lot of writing code and using Scala today. This makes me really happy. The best idea that I had today was to throw out any Java code on the CPU Simulator project, and do it all again in Scala. Why? Because if I write it in Java I won't learn as much. So, that is started, and a bunch of the new code is checked in.

Oh man I have a lot to talk about with Scala. I wonder if I should break it into many posts... I think I will.

But let me just say that I what I did today ties together everything I've been working on over the last four months. Doing the CPU Simulator in Scala helps me with languages, language design, IDE's, unit testing, compilers, reading code, preparing to teach classes, everything...

I was sick today, yet able to do work. I didn't have much energy, but sitting here was fine. Mostly I didn't want to get other people sick so I didn't go to work. Anyway, I did some of my best work today, and I was able to come up with a lot of really good ideas and I want to write them down before they are gone forever.

More on Reading Code

Let's revisit reading code and bring in some extra twists. (Hint: Debuggers are WRONG)

First, I know for a fact that I've read a lot of really really awful code. So based on what I said the other day, does this mean that I'm going to write really awful code? I like to think not. I'd like to think that it helps me understand what bad code is, how to read it and how NOT to write it.

Does this help me write great code? Most definitely not. To do that you need to read great code.

But, let's go back to that point about understanding the bad code. I can read bad code pretty well. I've been doing it for years. Sometimes I can actually get into the head of the developer (believe it or not, I used to write some pretty bad stuff, haven't we all?). Anyway, since I can read it well, this is just another reason I don't need to use the debugger.

By actually reading the damn code I can figure out whats going on. A well placed assertion in a unit test can confirm my beliefs. Sure, I could have used a well place break statement, but then I might be tempted to start stepping though code and wasting hours. Well thought out assertions in unit tests not only make the debugger basically useless to me, but give me regression testing going forward.

This would all be for naught if I couldn't read bad code. I read it, I understand it, I don't need the damn debugger to tell me what I already know, I write tests, I improve code.

I'm betting this: people spending hours using the debugger just need to learn how to read code better.

CPU Simulator on Google Code

No one might actually contribute, except myself, but I put my CPU Simulator project up on http://code.google.com/p/cpusimulator.

This wasn't just for the purpose of generating interest in this project, which is likely uninteresting to most people, but it was my first venture into creating/hosting my own project somewhere in the world. This is something that any self respecting developer should do at some point.

Overall I think Google Code is fabulous. I had my project up in minutes, with my code in Subversion. You get a wiki, downloads, administration, and a number of other things automatically.

Also, and awesomely, this helps me solve a major problem. I've been bitching that I have no way to easily link to code that I've written. Well, now, see this: http://cpusimulator.googlecode.com/svn/trunk/src/main/com/joshcough/cpu/gates/NorGate.java. Totally awesome.

I was disappointed that you only get 10 projects lifetime, but I guess I'll have to choose them wisely. Maybe if I get to be a teacher, and I'm using several projects for teaching, they will lift that limit.

Anyway, I'm really happy. Great day.

Reading Code

I haven't written and songs in a while. Way too long. Like, maybe a year. Terrible. It dawned on me just now (though I'm sure I knew it a long time ago) - I write more songs, and better songs, when I'm playing other peoples music. This is especially true when the music is difficult for me to play in some way (maybe the guitar part is hard, maybe the vocals are hard, maybe the rhythm is weird).

Notice I said "playing" other peoples music and not "listening" to. However, when I'm listening to more music, I still write more than I do when I'm not. Its just that playing is even better.

I not sure if I tie playing and listening to music to two different actions in code reading. I might try here, but the real point is that I need to read more code. And, it has to be good code of course. I need to read good code, and a lot of it. If I do my, code will become better and better.

I suppose listening to music is like glancing over code once. You want to see it to know what it does, but you don't really care to understand the thought process behind it. I guess you don't have to do that when you are playing someone else's song, but I usually do. So playing someone else's music is like, reading code really hard. Getting into the head of the coder, like getting into the head of the song writer. You can just glance at code, and just listen to a song. But, if you want to get better, you have to really concentrate on it. The better the song, the better the code, the more work put in, the better the results.

At Oswego I don't think they did enough to say that we should always be reading good code. I think most schools probably don't stress this enough unfortunately. And, even more unfortunately, most of my professional career has been filled with terrible code. Because of those two things, I didn't read much code that was any good. I didn't even know that I should.

When I struggled for a few years after college, it wasn't really obvious what the problem was. I was far and away the most talented guy in my class (I'm not even ashamed to act arrogant about this anymore, its just plain true), yet it didn't seem to translate to professional success. Finally I started reading books. Not so much reading code, but lots and lots of books. Things started looking up.

I still haven't read good code though. Well, not that much of it. I need to read more. I'm certain that when I do my code will improve, maybe even dramatically. So, I plan to attempt to find some books on code reading, potentially this one: http://www.spinellis.gr/codereading/. But, thats obviously not enough. I need choose some good code to read.

What are some good OSS projects to start reading? I read through CruiseControl Java a bit, and it was ok. But it was a little bit boring. I suppose it helps to pick something I'm familiar with. I think the java.util.concurrent that Dr. Lea wrote is the best place to start. It might be Java, which I'm getting sick of, but I'm certain its some of the most well written code there is.

But here is something else important. I'd like to attempt to put together a bunch of code, somehow ordered by increasing difficulty. Why? So I could develop my own college course in code reading. It would be so fun to have a bunch of stuff in a bunch of different languages that gets more and more difficult to read, and have the students have to tell you what it does. And, add features to it. Oh man, what a good course. Its so practical too, thats what most of my development has been (though I wish it wasn't that way). Its been mostly - here is this code base, and I need you to add this feature to it.

I think this is an essential class probably missing from most CS or SE programs. Maybe I'm wrong and just talking out of my ass, but I know it was missing at Oswego, and I consider Oswego to be one of the finest CS schools.