warpedjavaguy

Imperative by day and functional by night

Archive for the ‘scala’ Category

One Gwen Interpreter, Many Evaluation Engines

There is so much more that can be automated with Gherkin.

In the previous post, I announced the open sourcing of the gwen-interpreter project. In this post I will introduce the interpreter and evaluation engine concepts and describe the difference and relationship between them.

The Gwen interpreter translates Gherkin features into executable code. The code that each step is translated to is not defined in the interpreter itself, but rather in separate modules called evaluation engines. When a feature is executed, the interpreter delegates the processing of each step to a mixed in engine that you define or provide. This is necessary since evaluation varies across systems and it would be futile to try and code for every conceivable behavior in one implementation. For this reason Gwen abstracts the evaluation engine to support many implementations. In this way, you decide which engine to use based on the type of system you want to evaluate. For example, if you want to evaluate the behavior of a web application, then you can use our web engine. Each engine must prescribe a DSL and use at least one API to interact with a target system.

one-gwen-interpreter-many-engines

Engines can be defined to replicate any software process that is reproducible through one or more API’s.

There are many useful engines that can be built and they need not all be confined to just testing. Engines can be defined to automate, emulate, or simulate any process that is repeatable through software. Engines can also be built to generate data and other resources too.

In summary,

  • The interpreter reads Gherkin features and dispatches the processing of each step to a mixed in engine.
  • Engines define the DSL and processing to create conditions, perform actions, and assert expectations on target systems.

Hopefully many engines will emerge from the community and be shared.

Written by warpedjavaguy

May 27, 2014 at 12:17 am

Posted in automation, bdd, gherkin, scala

Tagged with

Gwen – A Gherkin DSL Interpreter

One platform for many types of automation.

Gherkin is a language for describing software behavior. Any software behavior. It makes sense to use it for evaluating software behavior too. But how can one evaluate any software behavior against any system with the one language?

A common language interpreter with an abstracted evaluation engine could be one way to do it.

This interpreter would accept Gherkin features as input and produce executing instructions as output. Specialised engines with specifically prescribed DSLs could be built and mixed in. The interpreter would support sequential or parallel execution. It would also produce evaluation reports and have a REPL console. It would provide all the necessary processing and tooling required to interpret Gherkin features and execute them. A public library of engines would emerge and be shared for everyone to download and use. The one interpreter would work with all of them.

It’s a simple idea that a colleague and I have been working on. We wrote it in Scala and open sourced it as a project called gwen.

gwen-logo-1

Check it out and have a play. We have released several stable versions of our web engine here: https://github.com/gwen-interpreter/gwen-web/releases

Written by warpedjavaguy

May 17, 2014 at 3:31 pm

Posted in automation, bdd, gherkin, scala

Tagged with

Hey Null, Don’t Touch My Monads!


Null handling.. we’ve been doing it completely wrong!

Nulls are a big problem! They are a most constant annoyance and the single root cause of all NullPointerExceptions. It is common practice in Java to defensively check for nulls everywhere. It would be nice if they could just go away. But they won’t because we’ve been using them on purpose to denote missing values. Almost every Java API uses nulls in this way.

When we integrate with Java API’s we have to check for nulls. Fortunately, Scala provides the Option monad to help deal with nulls. It is basically a container that can hold two types of values; Some or None (some value or no value). But for Java interoperability purposes, Some can also hold null. Is this a problem? Lets explore..

First, we’ll define a User class like this (overly simple I know)

case class User (name: String)

Now we’ll define a list of users and filter it

val users = List(User("Wendy"), User("Bob"))
users filter { _.name == "Bob" }

This yields List(User(Bob)). So far so good! Now lets redefine the user list by including a null entry.

val users = List(User("Wendy"), null, User("Bob"))
users filter { _.name == "Bob" }

Bang! NullPointerException! Lets fix it by checking for null.

users filter { u => u != null && u.name == "Bob" }

This yields List(User(Bob)) again. Good, but this is ugly. We don’t want to check for nulls. Let’s wrap every element in an Option instance.

users flatMap { Option(_) } filter { _.name == "Bob" }

Option(null) resolves to None and the expression yields List(User(Bob)) again. Nice! Now let’s try and wrap every element in a Some instance instead and see what happens.

users flatMap { Some(_) } filter { _.name == "Bob" }

Some(null) resolves to null and oh no, we get a NullPointerException! This is a problem. We want Some(null) to resolve to None. So lets define our own Some function that overrides this behavior.

def Some[T](x: T) = Option(x)
users flatMap { Some(_) } filter { _.name == "Bob" }

Now Some(null) returns Option(null) which resolves to None and the expression yields List(User(Bob)) as expected. Ok, so we’ve solved the Some(null) problem. Now lets look at another null problem. Lets blindly extract the second user element in the list (the null entry) and print the name property.

val user = users(1)
println(user.name)

The user reference is null and we get a NullPointerException. Oh dread, we didn’t check for null. Let’s do that.

if (user != null) {
  println(user.name)
}

Now we skip the printing of the name if the reference is null. But we don’t want to check for nulls. So lets wrap the null user in an Option and use foreach.

Option(user) foreach { u => println(u.name) }

Option(null) resolves to None and all is good. With our overriding Some function still in scope, we can do the same using Some also.

Some(user) foreach { u => println(u.name) }

Just like before, our call to Some(null) returns Option(null) which resolves to None and we’re good. But we want cleaner code that looks like this:

user foreach { u => println(u.name) }

This results in a compile error because foreach is not a member of User. But we can fix that by making our overriding Some function implicit. With this implicit in scope, Scala converts user to Option(user) and the above will now work.

implicit def Some[T](x: T) = Option(x)
user foreach { u => println(u.name) }

Taking this a step further, we can map the user name and print it like this. If the user is null, the name is never mapped and never printed.

user map { _.name } foreach println

Nulls be gone! 🙂

Now of course there are many cases in Java where nulls are legitimate values, and for this reason Scala supports Some(null) = null. But as shown above, that doesn’t mean we can’t override that with Some(null) = None.

Written by warpedjavaguy

June 8, 2011 at 4:35 am

Posted in java, scala

The “Scala is too Complex” Conspiracy


They don’t want pragmatic Scala programmers.

 

The “Scala is too complex for the average programmer” movement is disturbing. It conspires that Scala is too difficult for the average programmer to learn and that it is too academic. Scala is a hybrid programming language that is object oriented and functional. Java is a programming language that is object oriented and imperative. This means that Java programmers have no functional programming power.

This year I read Programming in Scala and practiced some functional programming. I converted some Java code I had lying around to Scala and gained some hands on experience with case classes, pattern matching, lazy evaluation, implicit conversions, lambdas, and closures. I also reduced and folded lists and wrote curried functions. I was pleasantly shocked and surprised!

It is true that moving from object oriented to functional programming requires a shift in mindset. It is true also that many Java programmers are already thinking functionally but are unaware of it. In Java we use immutable objects when programming for concurrency. We use anonymous inner classes to simulate lambdas and closures. We use iterators and predicates to simulate list comprehensions. We recognize these and other functional concepts but implement them in roundabout ways because there is no direct support for them in the Java language.

Fortunately Java 7 is looking to add lambda support to the language so we will soon no longer have to write anonymous inner classes wherever single method interfaces and abstract classes (SAM types) are expected. In the meantime Scala has emerged as a functional language that Java programmers can learn and transition to without sacrificing their object oriented skills and without leaving the JVM platform.

For any programmer who has not looked at Scala or who has been deterred by a “too complex” conspirator, here are some code samples..

Case classes

Lets create a class named Path that accepts a source and destination city as two separate characters and exposes them as public read only properties.

case class Path (origin: Char, destination: Char)

Prefixing a class definition with the “case” keyword automatically exposes constructor arguments as public read only properties. It also adds a factory method to your class so you don’t have to instantiate it with new, so Path(‘A’, ‘B’) will suffice for example. It also provides a toString method that returns a string literal like Path(A,B). You also get a natural implementation of the hashCode and equals methods. You get constructor pattern matching support too. All this for free with a one liner case class.

Factory method with pattern matching

Now lets create a factory method that accepts a string, parses it, and returns a Path instance. For example, passing the string “AB” should return a Path(‘A’, ‘B’) instance whereas passing the string “ABC” should fail.

object Path {	
  val PathRE = "^([A-Z]{1})([A-Z]{1})$".r
  def apply(pathStr: String): Path = pathStr match {
      case PathRE(origin, destination) 
      	=> Path(origin(0), destination(0))
      case _ 
      	=> throw new IllegalArgumentException(pathStr)
  }
}

Now we can instantiate a Path as Path(“AB”) in addition to Path(‘A’, ‘B’). Any string that does not contain exactly two characters that are not between A and Z will result in an IllegalArgumentException. So the strings “a”, “1”, “A1”, and “ABC” will all fail construction. As a safeguard we can add an assert statement to the Path constructor to ensure that the source and destination cities are never equal like this:

case class Path (origin: Char, destination: Char) {
  assert (origin != destination, "origin and destination are same")
}

Implicit conversion

Now lets make it possible to assign the string literal “AB” directly to any Path type anywhere so that we don’t have to call the factory method explicitly. We do this by prefixing our apply(String) factory method with the keyword implicit as shown below:

implicit def apply(pathStr: String): Path

Now the string literal “AB” can be accepted anywhere where a Path instance is expected.

Folding Lists

Now suppose we want to write an application that accepts a list of Path string literals from the command line. We can convert the incoming list of Path strings to a Set of Path instances by using a fold left operation. The following creates a new empty Set and adds to it every Path in the incoming list. Each string in the list is automatically converted to a Path instance through implicit conversion.

def main(args: Array[String]) {
  val pathSet = (Set[Path]() /: args) (_+_)
}

Lambda expressions

Now lets say we have already written a function named find, that finds all the routes from one city to another based on some route condition. This function accepts two arguments, a Path containing the from and to cities, and a predicate lambda expression. The signature looks like this:

def find(path: Path, predicate: Route => Boolean): List[Route]

We can invoke this function to find (for example) all the routes from city ‘A’ to city ‘E’ having less than 3 stops like this:

val routes = find("AE", route => route.stops < 3)

Currying

We can curry the find function by splitting its two argument parameter list into two one argument parameter lists like this:

def find(path: Path)(predicate: Route => Boolean): List[Route]

Now when we invoke the find function with a Path argument we get a second function that we can then invoke with the predicate argument to get the result. We can invoke our curried function like this:

val routes = find("AE")(route => route.stops < 3)

Scala allows us to optionally wrap the sole argument to a single argument function in curly braces instead of parenthesis. So we can also invoke our curried function like this:

val routes = find("AE") { route => route.stops < 3 }

Now our call to the find function looks like a built in Scala construct.

Is Scala too Complex?

If you think that the above Scala code is too complex then I urge you to try and achieve the same in Java with less complexity.

Written by warpedjavaguy

August 2, 2010 at 11:14 pm

Posted in java, programming, scala

%d bloggers like this: