Stay on Target

Speaking at CukeUp! NYC 2014 - Acceptance Tests: Beyond Write-Once

I'm excited to announce that I'll be speaking at CukeUp! 2014 in New York City on September 30, 2014. I'm presenting a session entitled "Acceptance Tests: Beyond Write-Once" where I'll share some things I've learned about working on acceptance tests in agile teams.

There's a fantastic lineup of speakers including Eric Evans, George Dinwiddie, Aslay Hellesøy, Matt Wynne, and more. I'm looking forward to their presentations!

CukeUp! takes place on Tuesday, September 30th and Wednesday, October 1st at DUMBO Loft in Brooklyn, NY.  Tickets are still available at the time of this posting.  

Code Pattern: Separate Configuration from Behavior

Problem

You have an object that requires data from some other part of your system to do its job. The object has some code that gathers the data it needs from the other parts of the system, as well as methods to perform its services using that data.

You notice: - Tests for the object make surprising references to other parts of the system, leading the program reader to wonder, "Where did this come from?". Tests may be hard to write in the first place because of this problem. - The object is not able to be used in another context because it only supports one set of data - Changes to the data found in other parts of the system require changing this object as well as those other modules.

These problems can arise when an object knows how to collect the data it needs for the specific scenario it supports. The object's behavior is intermixed with its construction.

Therefore:

Pass in the data the object needs as a parameter, either via the constructor or as a method parameter. Move the logic that collects the data to an earlier step in the program, either handled by the object that calls this one, or to some code that constructs a group of objects needed for this particular scenario. For some programs, this might be in the entry point (for example, the main() function in a Java standalone program).

Example:

Bane has an object called ServiceMaker which is responsible for creating services. There are several different types of services, each of which may be created in different ways. The ServiceMaker simplifies this so that clients only need ask for objects by name and the ServiceMaker returns them a correctly instantiated instance.

The ServiceMaker keeps a collection of all the things it knows how to make as a map where keys are the names of the services that can be created, and the values are objects that respond to the 'make' message.

For example, that map might look something like:

@makeables = { 'NeverListen' => an object, 'NeverRespond' => an object, … }

At the beginning of the refactoring, the code for the ServiceMaker looked something like this:

class ServiceMaker
  def initialize
    @makeables = initialize_makeables
  end

  def create(name)
    # Simplified - for example
    @makeables.fetch(name).make(...)   
  end

  # Other methods omitted

  private

  def initialize_makeables
    # Return a hash by looking in some Bane constants
    # The specifics of how these are created are not important,
    # but it is important to know that this code has some logic.
    Bane::Services::EXPORTED.map { … }
      .append(Bane::Behaviors::EXPORTED.map { … })
  end
end

Which referred to some constants:

module Bane
  module Services
    EXPORTED = ... # a list of services
  end
end

module Bane
  module Behaviors
    EXPORTED = ... # another list of services
  end
end

With a sample test:

def test_can_make_services_and_behaviors
    maker = ServiceMaker.new
    service = maker.create('NeverRespond')
    # verify the NeverRespond service is created
end

In ServiceMaker's initialize_makeables you see that it uses a few different constants and applies some sort of map function, adds the hashes together, and returns a Hash object.

In addition, the tests for the ServiceMaker require some setup, since they depend upon constants from outside of this class. By looking at the test code, it's not obvious how the known set of "makeables" is constructed:

def test_can_make_services_and_behaviors
    maker = ServiceMaker.new
    service = maker.create('NeverRespond')
    # verify the NeverRespond service is created
end

Note that the test code asks for the 'NeverRespond' service by name - but nowhere in the test is it clear where that name comes from. It's not obvious whether the ServiceMaker should be able to create one of those or not!

The ServiceMaker object is context dependent; it knows about how it fits in with the rest of the system. You can see that it references the Bane::Services::EXPORTED and Bane::Behaviors::EXPORTED constants.

This class knows two things:

1. Here's all the things I can make (by creating @makeables)
2. Here's how I make the things I know how to make (using @makeables and sending the make message)

If I add more types of makeables, it would mean that I'd need to change code in the ServiceMaker object. That doesn't feel like such a big problem to me; Bane is not so big that I am worried I won't know where this code would come from. But it also means that any time I wanted to change the list of makeables, I'd need to change the EXPORTED constants (possibly adding or removing some new sources of makeables) as well as the ServiceMaker. This breaks the "Open/Closed Principle" - that classes should be closed for modification, but open for extension. Or said another way, it should be possible to change the behavior of the system by adding new objects rather than editing inside of classes.

To fix this problem, I can pass in all the things I can make to the object's constructor instead of creating them inside the ServiceMaker:

class ServiceMaker
  def initialize(makeables)
    @makeables = makeables
  end

  def create(name)
    # Simplified - for example
    @makeables.fetch(name).make(...)   
  end

  # Other methods omitted

end

Now the ServiceMaker object is only responsible for creating the things it knows how to make. We put the code to create the map of services somewhere higher up in the stack like so:

makeables = Bane::Services::EXPORTED.map { … }
      .append(Bane::Behaviors::EXPORTED.map { … })
maker = ServiceMaker.new(makeables)
# ...

This separates the program's configuration from its behavior. We specify how our object graph is created at the beginning of the program, and then the program executes.

Now the tests for ServiceMaker are much simpler, because we can pass in something concrete:

def test_makes_the_specified_makeable_given_its_name
    maker = ServiceMaker.new({'NeverRespond' => FakeMaker.new('I never respond')})
    service = maker.create('NeverRespond')
    assert_equal 'I never respond', service
end

class FakeMaker

  def initialize(description)
    @description = description
  end

  def make(...)
    @description
  end
end

Note that we can pass in a test double (FakeMaker) that is simple to use for our test; this fake maker responds to the 'make' that returns the given description.

Contraindications

If your object is part of a library that you distribute and you want to protect users from incorrectly configuring your object, you might want to keep the configuration as part of the object, or provide a way for users to get a correctly configured version of your object through a Factory Method.

Other References

• J. B. Rainsberger has a write-up of making an object content-independent which describes a similar pattern
• The Dependency Injection principle describes how to configure an object by passing in its dependencies

Improve Your iOS Frank Cucumber Acceptance Tests

Here are some tips I've learned to build more readable, flexible acceptance tests for iOS devices using Frank and Cucumber.  See the full article on the Cyrus Cylinder:

The Cyrus Cylinder: Improve Your iOS Frank Cucumber Acceptance Tests

Four Tips for Asking for Feedback

Feedback is a tool that helps me learn about my blind spots, where I’m helping people, and where I’m hindering. Sometimes I ask for feedback about a specific event or occasion, other times I ask for advice on a subject. Both types of requests aim to get information to help me improve.

via blog.cyrusinnovation.com

Here are four tips I've learned that help me get better feedback or advice.

The Cyrus Cylinder: Benefits From Writing Our First End-to-End Tests

My team had started working on an existing Ruby on Rails web application with a JavaScript-heavy front-end interface. Our goal was to help the client build a suite of automated tests and start practicing Test-Driven Development.

via blog.cyrusinnovation.com

I've started blogging as part of my job at Cyrus Innovation. Here's my first post, it's about my experiences starting to work on a legacy code base and beginning with an end-to-end test.

My Review of James Shore's and Diana Larsen's "The Art of Agile" Course

My first experience with Extreme Programming (XP) was in 2000 after reading the "Extreme Programming Explained" book by Kent Beck, and it got me pretty excited about building software in a new, collaborative way.  After taking "The Art of Agile" course* by James Shore and Diana Larsen last year, I felt a sense of excitement similar to when I learned about XP over 10 years ago.  The course refreshed me on the principles, values, and practices followed by high-performing Agile teams, and re-energized my pursuit of building great teams that deliver valuable software.  But the course wasn't just a refresher, it also contained new material that I felt made it relevant for today's market:

• Building products using techniques from The Lean Startup (including material and exercises about identifying Minimum Marketable Features)
• Starting off new projects on the right foot by building team trust, consensus on the project's purpose, and clear team working agreements.  (Diana is the co-author of a new book about this very topic - Liftoff)
• How teams can facilitate change in their workplace
• How to make XP's On-Site Customer role work on teams without an on-site customer

I took this course with my entire company -- yes, that means all forty-some people at Cyrus Innovation, from software developers to operations and sales folks, with experience levels ranging from new to Agile and Extreme Programming to seasoned practitioners.  We gave the course excellent reviews across the board; everyone walked away with something they could use immediately on their teams.  As a team member, it felt great to have a shared group experience and consensus about the fundamental way we work.

So here's the "Hair Club for Men" moment -- we at Cyrus Innovation like this course so much, and felt it was so valuable to us as a company, that we decided to partner with James and Diana to offer this course again to the public in New York.  It was a fun course, memorable, and interactive - including a fully immersive series of four iterations building a real software product.  I think this course could be valuable to people who are just learning about Agile software development and to folks with experience looking to get reinvigorated about Agile and XP.  And taken as a team, I think there are huge benefits in the form of shared context, vision, and momentum that can translate immediately to new or long-lived teams and projects.

For more details, check out artofagilenyc.com.

 

* Technically it's two courses in one week: "The Art of Agile Planning" and "The Art of Agile Delivery".

Stories of Adopting Alternative JVM Languages in Java Projects in Better Software Magazine

Groovy, JRuby, Scala, and Clojure are some of the most widely used alternative Java Virtual Machine (JVM) languages today.  I spoke with several developers who adopted one of these languages in a Java-based project.  This article ("Alternative JVM Languages for Java Projects") tells their stories - which language they picked, why they picked it, and how they integrated it with their existing Java code base or infrastructure.

This article includes stories from the following people:

• Moss Collum: Gradually migrating code from Java to Groovy
• Kris Nuttycombe: Starting to use Scala to write tests for a Java project
• Najati Imam: Seamlessly deploying JRuby on Rails in an existing Java infrastructure
• Bob McWhirter: Combining some of the best parts of Java with Ruby language to build something new: TorqueBox
• Dan Chamberlain: Using Clojure to more naturally and succinctly model the business problem domain

 

Download PDF

 

This article appears in the September/October 2011 issue of Better Software Magazine.

Thanks to Heather Shanholtzer, Lee Copeland, Jean Middleton, and Cheryl Burke at Better Software Magazine for many things - the opportunity to write this article, top-notch editing, and valuable feedback.  Thanks to my friends Alex Baranosky, Moss Collum, Paul Infield-Harm, Joe Leo, Jason Reid and colleagues at Cyrus Innovation for their formative suggestions for the article.

An Introduction to Scala article in November/December 2010 Better Software Magazine

Scala is a programming language that blends functional and object-oriented language features. Scala programs run on the Java Virtual Machine and can easily interact with Java code. Learn how Scala can yield concise, safe, and compatible code, and how you can start learning Scala on your own.

My article "An Introduction to Scala" is now in print in the November/December 2010 issue of Better Software Magazine.

Download PDF

See the online Sticky Notes and Further Reading sections for footnotes and further references.

Special thanks to Daniel Spiewak for the technical review and edits. Thanks to Paul Blair, Najati Imam, Eric Stolten, and Joe Leo for their reviews and feedback.  Thanks to Lee Copeland, Heather Shanholtzer, Cheryl Burke, and the publication team at Better Software Magazine for their support and top-notch editing.

Addendum

In the article I wrote "Scala is developed at a university—not funded commercially by a big company like Java and Sun/Oracle—so its resources are more limited."  Since the time of writing, Martin Odersky and colleagues have formed Scala Solutions, a company that provides commercial support, tools, and training for Scala.

Introducing Bane, a Test Harness for Server Connections

Bane is a tool that makes it easy to test your application in scenarios where any third-party server dependencies behave in unexpected ways.  This post explains why you might want to use Bane, how to get started, and the design motivations behind Bane. 

Problem: The World is Unsafe (For an Application)

If you are building an application, you may depend on third-party servers or other external sources for your data.  You may use any of the publicly available web services from companies like Google, Yahoo!, or Twitter.  Or perhaps you use web services in an internal business application to obtain data from authoritative sources.  Most of the time these services are reliable and work as you expect.

Yet however reliable these services claim to be, at some point they’ll behave in an unusual manner.  The servers may be busy and accept your connection but never respond, they might reply in an unexpected response format, or there might be network problems that require endless retransmits of the data - and that's just a few of the ways that things can go wrong.  It’s up to you to program defensively so that if the remote service fails, your application doesn’t fail as well.  Michael Nygard’s excellent book “Release It!” is full of patterns and anti-patterns for building applications that can survive in these situations; I can’t recommend it highly enough.

To make sure your application isn’t susceptible to external service failures, you should test your application under various hostile conditions.  However, getting your external services to behave in the desired fashion can be a real challenge.  Instead, Nygard recommends building a tool that can simulate various bad behaviors, as described in the chapter “Test Harness.”  

Introducing Bane

Bane is an open source implementation of the test harness described in “Release It!”  Bane is written in Ruby and is available as a Ruby gem.  To install it, you’ll need a working installation of Ruby.  Install Bane with “gem install bane” which makes an executable “bane” available from the command line.  To make sure Bane is installed correctly, type “bane” with no arguments from the command line.  You should see a usage message like this:

$ bane

Usage: bane port_number <servers>

All behaviors:

 - CloseAfterPause

 - CloseImmediately

 - DelugeResponse

 - DelugeResponseForEachLine

 - FixedResponse

 - FixedResponseForEachLine

 - HttpRefuseAllCredentials

 - NeverRespond

 - NewlineResponse

 - NewlineResponseForEachLine

 - RandomResponse

 - RandomResponseForEachLine

 - SlowResponse

 - SlowResponseForEachLine

Bane requires you specify a port number on which to start listening and a behavior to use to respond on that port.  A behavior is one of the several nefarious ways in which Bane can respond, such as never responding, sending random data, closing the connection immediately, etc.  Behaviors are named in CamelCase (e.g. NeverRespond, NewlineResponseForEachLine) because they correspond to Ruby classes.

A Usage Example

Imagine you’ve built an application to track financial investment portfolios.  All stock quotes are obtained via a third-party web service.  You’d like to see how your application behaves when the web service accepts your request but never sends a byte of data in response.  Let’s pretend that your stock quote service listens on port 8080.

Start up the NeverRespond behavior on port 8080, which accepts a connection but then never sends a response.

$ bane 8080 NeverRespond

[Tue Sep 28 10:49:25 2010] NeverRespond 127.0.0.1:8080 start

Point your application at port 8080 and see how your application behaves.   Notice that Bane logs the incoming connections:

[Tue Sep 28 10:50:05 2010] NeverRespond 127.0.0.1:8080 client:61459 127.0.0.1<127.0.0.1> connect

You may need to add timeouts or other failure strategies to keep your application functioning under this scenario.  Consult “Release It!” for more information and other alternatives.

Bane comes with several bad behaviors you can use to test out your application in the manner described above.  See the README and wiki pages for more information.

The Design Motivations Behind Bane

Before I created Bane, I used to write little one-off scripts to create these badly behaving servers.  They aren’t much work; Ruby’s standard library includes a GServer class that makes it easy to quickly create a multithreaded TCP/IP server.  In fact, if you look at the source code, you’ll see that Bane uses GServer internally.  So why not just create these little servers each time by hand?

It turns out that each time I had to create one, I’d take about five minutes to bring up the RDoc and get all the parameters right.  So I created Bane to have all these common bad behaviors available in just a few seconds.  Right now Bane only supports two response protocols: send a response immediately upon connection and respond after each newline sent by the client.  I haven’t needed other response protocols on my projects yet, but it should be simple to create variations that respond after every n bytes, etc.  

However, if it turns out there needs to be some advanced protocol (e.g. respond after certain keywords, preserve state, etc.) then you may be better off spending the five to ten minutes to write your own server in Ruby using GServer or Sinatra, or some other language of your choice.  My goal is to keep Bane easy to use for common cases, to get a bad behavior up and running in a few seconds rather than five minutes.

Manual or Automated?

I use Bane primarily for manual exploratory tests, and write unit tests around my applications to create fast, repeatable automated tests.   Typically I use Bane in my consulting work to test out an existing application and see how it behaves, find the failure modes, write automated unit tests to expose the behavior, and then fix the problem by applying the patterns described in “Release It!”  Many of these unit tests use test doubles to throw exceptions that would be created by the I/O library in use.

That said, Bane provides an API through the Bane::Launcher class for automation in Ruby.  Take a look at Bane’s integration tests and the examples folder in the source distribution for an example of this API in use.

How to Contribute

Bane is open source and I welcome your feedback or contributions.  Here are a few ways you can contribute:

Provide Feedback: Please take Bane for a spin on your project and let me know if it helps, where it didn’t, and any suggestions for enhancements.

Write new behaviors: Fork Bane on GitHub and contribute useful bad behaviors or any other items described in “Release It!” which are not yet implemented (see the README for a list).  In particular, Bane does not yet support any of the low-level protocol errors in “Release It!”, such as the remote end endlessly sending TCP/IP resend packets.  To my knowledge, this low-level behavior is not possible with Ruby’s I/O library and requires a C extension.

Code Reviews: If you know Ruby and have some ideas about how to improve the code, please fork Bane and suggest some changes.

For more information

• Bane at GitHub
• Bane’s FAQ
• E-mail me at dan at danielwellman dot com

More Thoughts on Scala's Option Class

After reading a post by Cédric Beust that linked to an earlier article I wrote about Scala's Option class, I’ve decided to write about what I’ve learned about Option in the past two years.  Cédric brought up some good points about how that article’s pattern matching example using maps doesn’t feel drastically different than checking for nulls in Java.   

The code examples in the previous blog post demonstrate using Option with pattern matching.  I found this to be an easy way to learn about pattern matching, however after reading and writing more Scala code, I’ve learned that there are more efficient ways to use Option:

1. Use the getOrElse() function for simple this-or-that cases.  The Map getOrElse(key, default) function will return value contained in the Some() container or the specified default otherwise.  Using the map from the example above, you could write something like this:

scala> val map = Map("Hi" -> "Dan", "Hello" -> null)
map: scala.collection.immutable.Map[java.lang.String,java.lang.String] = Map((Hi,Dan), (Hello,null))

scala> map.getOrElse("Hi", "No key with that name!")
res1: java.lang.String = Dan

scala> val result = map.getOrElse("Gutentag", "No key with that name!")
res2: java.lang.String = No key with that name!

In our example, since “Gutentag” doesn’t exist in the map, result will be the “No key with that name!” message.  (Technically this is not the same as the original pattern matching example, as this code doesn’t append the “Found value” string before a found key, but for this example the important part is “or else” functionality.)  This code feels shorter and more concise to me.

Note that the Option class also has a getOrElse(): 

Some(“foo”).getOrElse(“Nothing!”) // returns “foo” 

2. Use Options and for comprehensions to simplify a series of calls which may return a result or no value.   Daniel Spiewak’s comment on Cédric’s blog post provides a quick example of this; I’ll post the code here, but please do read his comment for a detailed explanation (and some more thoughts on Option in Scala):

val value = for {
 row <- database fetchRowById 42
 key <- row get "port_key"
 value <- myMap get key
} yield value
val result = value getOrElse defaultValue

This code will set result to either a Some value if there’s a database record with the given row id, that row has a “port_key” value, and myMap holds an entry with the referenced key or None if any of those lookups fail.  The getOrElse call will either return the value stored in myMap or else some default value.

The concise for comprehension syntax works well when you can accept a default value in the event of failure (an “all or nothing” design approach), but if you need to handle an error at each individual step, you’ll need to do something else.  Lift’s Box class is similar to Option but has hooks for error handling.  

3. Option is about programmer intent. JSR-305 has proposed @NonNull and @Null annotations for Java to allow programmers to indicate that a method may or may not return null.  Scala’s Option class provides a similar indication to programmers; this function may return a value (Some) or it may not (None.)  Java JSR-305-aware compilers can provide warnings at compile-time if a null value might be dereferenced.  Scala’s compiler can also provide a warning if you use pattern matching against an Option class and don’t check for both Some and None cases.

However, Scala’s Option class gives you one thing Java’s null value does not – behavior.  Option defines methods that you may safely call (like getOrElse, map, etc.) whether you have a result (Some) or not (None.)  Using these methods along with for comprehensions seems to yield fairly concise code.