For greenfield projects you can plan from day one how to setup the test to easily include the database interaction but with legacy projects it is not always that easy.

Dealing with legacy code

Let’s face it: Testing is hard.

I do not mean it is hard to understand. The complexity is not inherently attached to the concept of testing but (I found in most cases) a by-product of tooling + environment + database.

That is the reason why I think adding testing to a legacy system can be quite challenging. We did not choose the tooling, nor the database nor did we set up the environment to be test friendly.

So where to start with testing?

One option is to start by adding unit tests into the codebase, but that could be a paramount effort considering that quite often the legacy code was not written with testability in mind. A lot of change, a lot of risk.

On the other hand acceptance testing is the perfect candidate.

Why? Acceptance Testing puts the focus on testing end to end. Given a certain input, run it through the system and make sure the output is what we expect to see.

It works for web applications, web apis, libraries, desktop applications, you name it. And also, in many cases we will not need to modify the code behaviour at all.

All that is fine and dandy, but what about the database? We may be able to create a local copy of the database to test, but what are we going to do with data generation, logic stored in the database, etc?

A perfect world

Let’s pause and imagine for just a few paragraphs that instead of using a database the system under test uses an HTTP API to get all the information it needs.

If that was the case then we could implement acceptance testing very easily by doing something like the following pseudo algorithm:

• Launch a fake HTTP server listening on the URI expected by the system.
• Create some data that will work for my test case.
• When the application does the call, return that data.
• Validate the case worked as expected.
• Shutdown the server.

Neat right? This approach has many benefits.

First, we keep modifications of the system under test to the bare minimum.

Second, there are lots of tools in multiple languages that can help us with such a task. We can choose the same environment or one that is completely different. Whichever works better for our needs.

Third, these steps can be easily automated and ran when it is convenient and useful.

Ok, the break is over.

Back to reality

To change all the database related code to start using some kind of web API could be a huge risk and effort.

Such amount of refactoring may cripple your project for a long time, and not even produce a positive result.

Having said that, what if we use the same idea but with a small twist?.

Leave the database code alone

Well, not alone alone, but let’s hide it behind a very thin wrapper.

The goal is that instead of directly hitting the database (or whichever function or class is being used) we are going to call a proxy that is sole job is to forward the call to the same code we were using before.

The main difference is that the Proxy talks about the domain. If we were fetching some Customer object from the database, then the proxy will have a way to do so and return a Customer collection.

So the database interaction, ORM mapping, etc, stays hidden.

To illustrate the idea with a bit of code, let’s imagine a class in charge of finding customers in order to show them:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public class CustomersController {

  public CustomerView index() {

    String query = "select NAME, ADDRESS, BIRTH_DATE from CUSTOMERS";

    ResultSet rs = dbConnection.createStatement().executeQuery(query);

    List<Customer> customers = new ArrayList<Customer>();

    while(rs.next()) { customers.add(loadCustomer(rs)); }

    return new CustomerView(customers);
  }

  private Customer loadCustomer(ResultSet rs) { ...... }
}

The first step would be to create an interface and abstract the query to the database:

1
2
3

public interface CustomersQuery {
  List<Customer> getCustomers();
}

And a default implementation that does the database query:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

public class DatabaseCustomerQuery implements CustomersQuery {

  public List<Customer> getCustomers() {

    String query = "select NAME, ADDRESS, BIRTH_DATE from CUSTOMERS";

    ResultSet rs = dbConnection.createStatement().executeQuery(query);

    List<Customer> customers = new ArrayList<Customer>();

    while(rs.next()) { customers.add(loadCustomer(rs)); }

    return customers;
  }

  private Customer loadCustomer(ResultSet rs) { ...... }
}

And the original class now it uses the interface:

1
2
3
4
5
6
7

public class CustomersController {

  public CustomerView index() {
    return new CustomerView(this.customersQuery.getCustomers());
  }
}

Mock the proxy

When testing the system, the library in charge of proxying the interaction to the database could be switched to a different one that does an HTTP call to a URI and returns the result based on the response.

By using an HTTP call, then the test will pose as the expected source of data and respond based on the needs of each case.

Following the previous example, we could implement a class that gets the customers data using an HTTP call to the test URI.

The example uses Jackson to load the json content.

1
2
3
4
5
6
7
8
9
10
11
12

public class HttpCustomersQuery implements CustomerQuery {

  public List<Customer> getCustomers() {
    HttpGet httpGet = new HttpGet(testUrl + "/customers");
    HttpResponse response = httpclient.execute(httpGet);

    ObjectMapper mapper = new ObjectMapper();
    List<Customer> customers = mapper.readValue(response.getEntity().getContent(), new TypeReference<List<Customer>>(){});

    return customers;
  }
}

The last step, when running the tests we will launch the HTTP server to serve the JSON customers:

Here I am using WireMock to set up the response.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

@Test
public void testCustomersView()  {

  List<Customer> expected = createSomeFakeCustomers();

  String serializedCustomers = JSON.write(expeted);

  stubFor(get(urlEqualTo("/customers"))
            .willReturn(aResponse()
                .withStatus(200)
                .withHeader("Content-Type", "application/json")
                .withBody(serializedCustomers)));

  // run the system under test here
  runSystem();

  List<Customer> actual = getCustomersShown() ; // get the customers that are being shown

  assertThat(expected, is(actual));
}

Why bother with HTTP?

We could implement the “fake” version of the library as:

1
2
3
4
5
6
7
8
9
10
11

public class HttpCustomersQuery implements CustomerQuery {

  public List<Customer> getCustomers() {
    String jsonContent = loadResourceFrom("/resources/customers.json");

    ObjectMapper mapper = new ObjectMapper();
    List<Customer> customers = mapper.readValue(jsonContent, new TypeReference<List<Customer>>(){});

    return customers;
  }
}

However this approach may limit our ability to separate completely the acceptance test implementation from the system we want to test.

Having an external server to pose as data source provides flexibility and could simplify quite a bit the test implementation because it gives us the freedom to choose any tool that we may see fit to do the actual implementation.

This technique could simplify manual testing as well. The test scenario data could be setup, then the system launched and wait for manual confirmation to ensure it works as expected.

1
2
3

Given the customers are loaded             # All the customers in the JSON file are loaded
When listing the customers                 # Launch the system to show the customers
Then every customer name shows in the list # Ensure all customers are shown

Change impact

The change will be localized. Modifying a particular functionality of the system does not affect how other parts of the system work nor major refactoring effort is required.

Of course there will be some code change, but hopefully very small and just to hide the database related code behind a very thin wrapper.

Once the acceptance tests start to roll, each new test will be easier and easier.

Not only the system will have a new safety net that becomes larger and larger with every test, but the quality will grow as well.

But what can we do about it? To start let's review the meaning of null values ...

Modeling optional results

Finding Customers

Finding operations are very common. Given a Customer class, a Find method could look like this:

1

public Customer Find(Query query) ;

Now what happens when the customer can not be found? Possible options are:

• Throw an exception: Why though? Where is the exceptional case? Trying to find a Customer has the possible scenario of not beign found.

• Return null to mean nothing was found. But are we positive we are getting a null for that reason and not other? And what can we do with the null value after?

• Return a NullObject that represents Customer null value. That could work to show some of the customer's data, if we expect strings or something similar. But for most cases this won't be enough.

Parsing Integers

In C# you can use Int32.parse or Int32.tryParse to do the job. The former throws an Exception when the string can not be parsed into an int and the later returns a Bool indicating if the operation succeeded using an out parameter for the value.

The first approach is not that intuitive. I want to get a result, not to catch an exception.

The second one with the boolean result seems to go in the right direction but having an out parameter complicates things, and makes it hard to understand and hard to pass to another function, etc.

Optional values

F# has a very simple way to deal with this by creating a Discriminated Union with only two values:

1
2
3

type Option<'T> = 
  | Some of 'T 
  | None

Now finding customers has a very clear interface:

1

let tryFindCustomer (q: query) : Option<Customer>

Parse clearly can succeed giving the parsed result or fail, therefore the result is Optional.

1
2
3
4

let tryParseInt (s:string) =
  match Int32.TryParse(s) with
  | true, result -> Some result
  | false, _     -> None

NOTE: out parameters are converted tuples in F#.

As a convention is common to call functions trySomeAction when the action can fail and return an optional value.

Working with optional values

Modeling optional values is a great start. Using an optional value makes very clear the fact that the caller has the responsibility to handle the possiblity of having None as a result.

Having clear meaning improves clarity, intent, error handling, and there is no null that can cause problems.

However, in terms of handling the result, are we that much better than before?

Of course we could check always for Some or None and handle the result, but where is the fun in that?

The key to create a great abstraction is usage. After seeing the same bit of code used again and again we could be confident that abstracting the behaviour is going to be really useful.

To avoid doing a match on Option types luckily we have a series of helper functions that address most common scenarios.

Many of these functions live in the FSharpx library.

Using defaults

To obtain the value from an Option we can use Option.get:

1
2
3
4

let get = 
  function
  | Some a -> a
  | None   -> failwith "Nothing to get!"

(what's that function? Here is an explanation about pattern maching function)

Notice that get throws an exception when there is nothing to get.

Throwing exception (and catching it) is ok, but makes hard to compose the result or transform it.

Instead why not use a default value when there is None? (Taken from FSharpx):

1
2
3
4

let getOrElse v = 
  function
  | Some a -> a
  | None   -> v

Knowing that it can fail, and having a default value help us write code that can use a default value and keep going:

1
2
3
4
5

let doWebRequest countStr =
  countStr
  |> tryParse
  |> Option.getOrElse 10
  |> processRequest

Applying functions

Another common scenario is to apply a function when we get a result or just do nothing otherwise:

For example, the following code will only print the message when tryParse returns Some:

1
2
3
4

let doWebRequest param =
  param
  |> tryParse
  |> Option.iter (printf "The result is %d")

And the implementation:

1
2
3
4

let iter f = 
  function
  | Some a -> f a
  | None   -> unit

Shortcircuit None

iter is useful to execute a function when there is Some value returned, but is common to use the value somehow and transform it into something else.

For that we can use the map function:

1
2
3
4

let map f = 
  function
  | Some a -> f a |> Some
  | None   -> None

This is a bit different. Not only the function passed as parameter is applied after unboxing the value, but the result is boxed back into an Option. Once an Option always an Option.

Imagine a railway and a train that once hits the value None switches to a None railway and bypasses any operation that comes after. Thus the shortcircuit.

1
2
3
4
5
6

let queryCustomers quantity = [] // silly implementation

let doWebRequest req =
  req.tryGetParam "customers"
  |> Option.map queryCustomers         // Shortcircuit with None
  |> Option.getOrElse invalidRequest   // uses the default

Mapping to Option

Another common case, very similar to map, is to use a function that transforms the boxed value and returns an Option.

1
2
3
4

let bind f = 
  function
  | Some a -> f a 
  | None   -> None

For example the parameter that represents the customer id is a string, and we need to parse it into an int. Getting the parameter can return a None and the parse function could return a None as well.

1
2
3
4
5

let doWebRequest req =
  req.tryGetParam "customerId"
  |> Option.bind Int32.tryParse       // Shortcircuit if None
  |> Option.map  findCUstomer         // Shortcircuit if None
  |> Option.getOrElse invalidRequest

Multiple optional values

So far so good with one parameter. But what happens with more than one parameter? The goal is to shortcircuit and if one of the parameters is None then abort and just return None.

One option is to use FSharpx and the MaybeBuilder. I'm not going to discuss the details of how builders work but I will show you the practical usage to illustrate the point.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

type Result<'TData> = 
  | Success of 'TData
  | Error of string

let findCustomers count country city = ... // implement query

let invalidRequest = "Boooo! Not all parameters are present!"

let doWebRequest (req:Request) =
  maybe {
    let! strCount = req.tryGetParam "count"
    let! city     = req.tryGetParam "city"
    let! country  = req.tryGetParam "country"
    let! count    = Int32.tryParse strCount
    return findCustomers count country city
  }
  |> Option.map Success
  |> Option.getOrElse (invalidRequest |> Error)

In this scenario we have a happy path:

• All parameters are present, then the result is Success with the output of findCustomers.

And four unhappy paths:

• count is not present, then the maybe builder does shortcircuit to None and getOrElse returns an Error.
• city is not present, then the maybe builder does shortcircuit to None and getOrElse returns an Error.
• country is not present, then the maybe builder does shortcircuit to None and getOrElse returns an Error.
• count is present, but can not be parsed then ... shortcircuit ... and Error.

The let! is doing the unboxing from Option to the actual type, and when any of the expressions has the value None then the builder does the shortcircuit and returns None as result.

Applicative Style

Another way to write the same concept (sometimes a bit more clear) is to use the Applicative style by using operators that represent the operations that we already are using that also apply shortcircuit when possible.

For the functions we have used in the Option type the operators are:

1
2

<!> // is an alias for map
>>= // is an alias for bind

(Find all the definitions here).

To use them let's try to read the parameters from the request.

1
2

let city    = req.tryGetParam "city"
let country = req.tryGetParam "country"

Good, now count needs to be parsed as well, so we can use tryParse that returns an Option. What can we use when we need to apply a function that returns also an Option? Bind of course, or >>=.

1

let count = req.tryGetParam "count" >>= Int32.tryParse

All the parameters are parsed into Option and findCustomers can be invoked.

1

findCustomers <!> count ???? city ??? country

To apply a function over an Option we can use the operator <!> (map), but what about the other two parameters?

Let me rephrase, what happens when we apply a function that takes three parameters to just one parameter? Exactly! A partial application!

Same happens when applying the operator <!> to a function that takes three parameters, the difference is that the partially applied function gets boxed in an Option.

1
2
3

let count = req.tryGetParam "count" >>= Int32.tryParse 

findCustomers <!> count ... // returns an Option<int -> int -> Customer list>

Now we need to apply the boxed function to a boxed value, and for that we can use the operator <*> that takes a boxed function and a boxed value and returns the boxed version of applying the function to the value.

1

findCustomers <!> count <*> city  ... // partial application of the function to city

In this case we have two more parameters so the full version would be:

1
2
3
4
5
6
7
8
9
10

let findCustomers count city country = [] 

let doWebRequest (req:Request) =
  let city    = req.tryGetParam "city"
  let country = req.tryGetParam "country"
  let count   = req.tryGetParam "count" >>= Int32.tryParse 

  findCustomers <!> count <*> city <*> country
  |> Option.map Success
  |> Option.getOrElse (invalidRequest |> Error)

Summary

Using an Option to represent when a value may not be present has many advantages.

Not only is easier to deal with cases that produce no results, but also the code is clear an easy to follow.

Though here the code is in F# you could implement similar features in your favourite language.

(Check out Java 8 Optional class or this C# implementation of Maybe by Adam Krieger).

All the code can be found here. I included a series of tests that show how the builder and applicative style apply a shortcircuit when one of the parameters is missing.

Thanks to my good friend Shane for helping me to test the code in all platforms.

In the last Ruby Meetup we used Day 7 to illustrate how to use Rantly for properties testing.

It was my first try to solve Day 7 using Ruby, and I wanted to find an elegant, idiomatic, short way to do it...

Before we start

First I want to give a very big shout out to Eric Wastl for creating the Advent Of Code.

Try it out, and if you like it let Eric know!

Exploring the problem

SPOILER ALERT: Yes, we are going to talk about Day 7 and how to implement the solution. Feel free to do it on your own first.

The problem describes a circuit board with instructions to apply signals to circuits using bitwise logic operations.

The operations are:

- 123 -> x means that the signal 123 is provided to wire x.- x AND y -> z means that the bitwise AND of wire x and wire y   is provided to wire z.- p LSHIFT 2 -> q means that the value from wire p is left-shifted by 2   and then provided to wire q.- NOT e -> f means that the bitwise complement of the value from   wire e is provided to wire f.Other possible gates include OR (bitwise OR) and RSHIFT (right-shift).

I implemented the solution in Haskell and found out that not only the parsing was the challenge but also the fact that you get a list of instructions that can be in any order, so some instructions when evaluated may result in having no signal (no value).

For example, let's consider the following sequence of instructions:

lx -> a456 -> lx

When evaluating the first instruction, the wire lx has no signal yet, so it has to be reevaluated later.

Of course you could create an evaluation tree but that seemed a bit too much for the problem at hand. So I decided to do the following:

1. Parse instructions into commands
2. Repeat evaluating commands until all pass
3. Return the value of wire "a" from the board

The classy way

As soon as I read about instructions my mind started to race thinking about parsing and patterns.

My first thought was I could use the Interpreter Pattern to build a hierarchy of classes to evaluate expressions. But it seemed like an overkill.

Therefore, I decided to use classes to represent each command:

1
2
3
4
5
6

class AndCmd    ; end
class OrCmd     ; end
class LShiftCmd ; end
class RShiftCmd ; end
class NotCmd    ; end
class EvalCmd   ; end

Each class has two methods with clear responsibilities:

• parse(token1, token2, token3..., wire) Class factory method that parses the command and returns an instance of the command.

• wireIt(board) Instance method that evaluates the command to assign the result of the operation to the target wire.

The constructor of the class stores the operands and target wire.

1
2
3
4
5
6
7
8
9

class AndCmd
  def initialize(lhs, rhs, wire) ; @lhs, @rhs, @wire = [lhs, rhs, wire] end
  def wireIt(board) 
    # asign the @lhs & @rhs to the board
  end
  def self.parse(....)
    # parse the string to match the AND command and return a new instance
  end
end

The parse factory method receives the expected tokens. If the cmd token matches the string "AND" then returns an instance of AndCmd.

1
2
3

def self.parse(x, cmd, y, arrow, z)
  AndCmd.new(x, y, z) if cmd == "AND"
end

Abstracting the board

Evaluating the command was more complex because the values could be undefined. Some kind of validation was necessary.

I started using a Hash as a CircuitBoard and then checking if the values were defined. It got a bit more complicated when I realized I had to parse values, because I could get lx AND lb and also 1 AND ll.

Inspired by my Haskell solution I thought that a class that implements a short circuit evaluation could be very useful. That way, if one of the involved values was not defined the whole command was undefined.

To simplify board access and evaluation I created a Board class that handles the assignment plus the lookup.

The assign method takes a block that gets evaluated if all the values are defined, otherwise it is ignored.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

class Board
  attr_reader :wires                                           
  def initialize ; @wires = {} end                             
  def [](y) ; @wires[y] end

  def assign(wire, *exprs)                                     
    values = exprs.map { |exp| value exp }                     
    return nil if values.any?(&:nil?)·                         
    @wires[wire] = block_given? ? yield(*values) : values[0]   
  end                                                          

  private·                                                     
  def value(exp)                                               
    /\d+/.match(exp) ? exp.to_i : @wires[exp]                  
  end                                                          
end

This simplifies things quite a bit. Now the wireIt implementation only applies the operation when all the values are defined:

1
2
3

def wireIt(board)
  board.assign(@wire, @lhs, @rhs) { |l, r| l & r }
end

Parsing instructions into commands

To parse the string I created a parse method that splits the instruction into tokens (words) and finds a parsing factory method with the same amount of parameters that returns an actual instance of the command.

This is similar to a chain of responsibility where the parser tries to parse the instruction. If the parser cannot do it then the parser passes the instruction to the next parser in the chain until one of them succeeds. If no parser succeeds, nil is returned.

1
2
3
4
5
6
7
8

def parse(instruction)                                              
  tokens = instruction.split                                        
  [AssignCmd, AndCmd, OrCmd, RightShiftCmd, LeftShiftCmd, NotCmd]   
    .map    { |k| k.method(:parse) }                                
    .select { |m| m.parameters.length == tokens.length }            
    .map    { |m| m.call(*tokens) }                                 
    .find   { |cmd| cmd }·                                          
end

The main loop

The last bit of the exercise is to keep evaluating all commands until there are no failing commands left.

1
2
3
4
5
6
7
8

def wire(instructions)                                  
  cmds = instructions.map(&method(:parse))              
  board = Board.new                                     
  while !cmds.empty?                                    
    cmds = cmds.select { |cmd| cmd.wireIt(board).nil? } 
  end                                                   
  board                                                 
end

You can see the complete source here.

The Ruby way

After finishing the implementation using classes I started to wonder what would be more idiomatic to Ruby.

Classes are fine, but I wanted to explore the dynamic aspect of Ruby and use eval.

Parsing instructions

Instead of having a Class factory method to parse, I declared parse_xxx functions that return a string to be evaluated later for the expected command.

1
2
3
4
5
6
7

def board(exp) ; "board['#{exp}']" end

def expr(exp) ; /\d+/.match(exp) ? exp : board(exp) end

def parse_and(x, cmd, y, arrow, z) 
  cmd == "AND" && "#{board z} = #{expr x} & #{board y}" 
end

The main parse function now uses the parse_xxx functions instead. The parse chooses the function that has the same amount of parameters as the tokens in the instructions and also returns a string with the expression to be evaluated.

1
2
3
4
5
6
7
8

def parse(instruction)
  tokens = instruction.split
  [:parse_assign, :parse_and, :parse_or, :parse_rshift, :parse_lshift, :parse_not]
  .map    { |s| method(s) }
  .select { |m| m.parameters.length == tokens.length }                           
  .map    { |m| m.call(*tokens) }
  .find   { |cmd| cmd }
end

The main loop

The main loop is very similar to the main loop of the classy version with the difference that to get the actual value, eval is called for every command. If the command succeeds, the evaluation will return some kind of number.

1
2
3
4
5
6
7
8

def wire(instructions)                                                     
  cmds = instructions.map { |line| self.parse line }                       
  board = {}                                                               
  while !cmds.empty?·                                                      
    cmds = cmds.reject { |cmd| (eval(cmd) rescue nil).kind_of? Fixnum }    
  end                                                                      
  board                                                                    
end

The result

The solution seems simpler than using classes. The strings make each command quite transparent.

Probably, even the parsing could be combined into one function and reduce the amount of functions in general.

You can see the complete solution here.

The functional way

After the Classy and Ruby way I wanted to see if I could be a bit more functional.

The approach this time was to parse the instruction into a lambda that will evaluate the actual command.

I decided to reuse the Board class from the first solution to make the value evaluation easier and implement a short circuit when a value is not yet defined.

Parsing instructions into commands

Third time’s the charm! I reduced the amount of parsing functions by having a binary parsing function that uses a hash to decide which operation to apply.

1
2
3
4

def parse_bin(x, cmd, y, arrow, wire)                                 
  op = {"AND" => :&, "OR" => :|, "LSHIFT" => :<<, "RSHIFT" => :>>}[cmd]
  op && -> (board) { board.assign(wire, x, y, &op) }
end

The hash lookup decides which operation to use.

The general parse function is similar to the Ruby way:

1
2
3
4
5
6
7
8

def parse(instruction)
 tokens = instruction.split
 [:parse_assign, :parse_bin, :parse_not]
   .map    { |s| method(s) }
   .select { |m| m.parameters.length == tokens.length }
   .map    { |m| m.call(*tokens) }
   .find   { |cmd| cmd }
end

The main loop

Instead of using eval, the call method is used on each lambda to evaluate the command.

1
2
3
4
5
6
7
8

def wire(instructions)
  cmds = instructions.map { |line| parse line }
  board = Board.new
  while !cmds.empty?
    cmds = cmds.select { |cmd| cmd.call(board).nil? }
  end
  board
end

You can see the entire solution here.

The verdict

The version I like the most is the eval version because it is simple and straightforward.

The second best option, in my opinion, is the functional version because it uses the bitwise logic operators as functions.

Last but not least is the classy version. Using instances of classes does not seem to be necessary for this exercise because all parameters can be captured when creating the lambda closure for each instruction.

Which one is would you choose?

This time around I was working with @QuinnWilson and @AdamKrieger doing the Highest and lowest Kata using Ruby and RSpec.

Is a simple Kata but I wanted to put focus on TDD, self data generation and property testing...

The scenarios

I won't go into the TDD steps because I want to fast forward to data generation.

We created three tests, from the domain of the problem first we selected strings that contain only one number then the result should be that number as max and min.

1
2
3
4
5
6

context 'When the string has only one number' do                       
  it 'Returns the same number twice' do                                
    str = "1"                                                          
    expect(highest_lowest str).to eq "1 1"                             
  end                                                                  
end   

For our second scenario we thought that it would be easy if the sequence of numbers where already sorted, so the min and max are the first and last.

1
2
3
4
5
6

context 'When the numbers are sorted' do                               
  it 'returns the last and the first' do                               
    str = '-5 -2 8 12 32 150'                                          
    expect(highest_lowest str).to eq "150 -5"                          
  end                                                                  
end                                                                    

The last scenario includes all the strings with sequence of integers.

1
2
3
4
5
6

context 'For any string with one or more numbers separated by space' do
  it 'returns the max and the min' do                                  
    str = '22 -5 28 -294 33 1794 10000 2'                              
    expect(highest_lowest str).to eq "10000 -294"                      
  end                                                                  
end                                                                    

Ruby has a minmax method on Array but we wanted to do it using a fold. So here is our implementation:

1
2
3
4
5

def highest_lowest(str)
  str.split.map(&:to_i).inject([MIN, MAX]) do |mm, i|
    [[mm.first, i].max, [mm.last, i].min]
  end.join ' '
end                                                

Self generating data

We did write only one example on each scenario to start but now we wanted to cover more cases.

Not only I want to generate random data but I want to have a reasonable distribution of values anddescribe it as a property that the function has to satisfy.

Libraries like QuickCheck (for Haskell, main inspiration to others), FsCheck (for F#) and ScalaCheck (for Scala) do exactly that. For Ruby we used Rantly.

Single integer

The first scenario requires a string with one integer.

To do that with Rantly we can use the integer generator integer. After converting it to a string we have the input for the test.

Imagine a property that looks like:

Given a string with a single integer NThe result is a string like "{N} {N}"

1
2
3
4
5
6
7
8

it 'Returns the same number twice' do
  property_of {
    n = integer
    n.to_s
  }.check do |str, n|
    expect(highest_lowest str).to eq "#{n} #{n}"
  end
end

Rantly is going to generate 100 cases by default and check to make sure the equality holds for all of them.

Sorted integers

Having a sorted sequence of numbers is easy to specify where the min and max should be.

So the property could be something like (in pseudo formal but not so much english):

Given an ordered string of integersThen the first is the MIN and the last is the MAXAnd the result is a string like "{MAX} {MIN}"    

1
2
3
4
5
6
7
8
9
10

context 'When the numbers are sorted' do
  it 'returns the last and the first' do
    property_of {
      arr = array { integer }.sort
      [arr.join(' '), arr.last, arr.first]
    }.check { |str, max, min|
      expect(highest_lowest str).to eq "#{max} #{min}"
    }
  end
end

The general case

Thinking of the actual postcondition of the problem, the property could be something like:

Given any non empty collection of integersAnd exist MIN and MAX that belong to the collectionWhere MAX is the maximum and MIN is the minimumThen the result is a string like "{MAX} {MIN}"

Considering for a moment the domain (all the possible instances) of any non empty collection of integers. That would include sets of a single element and also sorted elements, thus we cover the other two scenarios.

I want to generate all the integers but at the same time have the max and min so I don't write the test duplicating the implementation to find maximum and minimum.

To do that, I will generate first the min and max and then add integers in between.

1
2
3
4
5
6
7
8
9

it 'returns the max and the min' do
  property_of {
    min, max = [integer, integer].minmax
    arr = array { range min, max } + [max, min]
    [arr.shuffle.join(' '), max, min]
  }.check(200) do |str, max, min|
    expect(highest_lowest str).to eq "#{max} #{min}"
  end
end

I changed the number of cases to 200 just to illustrate how to override the default.

Using properties

Properties can be very useful to help identify test cases plus data generation makes much easier to describe a scenario and find a domain for the test.

Having a combination of both property testing and example testing can be a good balance to have tests that are accurate and also descriptive.

How can we find balance between writing the right thing (BDD) and writing things right (TDD)?

A perfect world

Test Driven Development (TDD) makes you think. It’s not only about the test first approach but also about following some rules.

TDD, however, is not enough to ensure that you are building the features that address the client’s expectations.

Behaviour Driven Development (BDD) makes you think about the whole feature. Owners/champions participation helps you write the acceptance criteria and drive the implementation until the feature is implemented.

When you combine BDD and TDD you get the best of both worlds: you are able to match your clients’ expectations with high quality code and write the minimum amount of code possible.

Clearly both BDD and TDD are useful, however, is not always easy to implement both.

Ideally, to find balance you need to make sure you are well versed in both BDD and TDD, so you can be objective and, in the words of a great wizard, choose between what is easy and what is right.That means we need to overcome two major drawbacks (to start): the learning curve and poor tooling.

Learning curve

As with any new methodology both TDD and BDD share a big drawback: the learning curve. Not only you need to learn how to implement each of them but also how to combine them.

This part is crucial to find balance between these methodologies. If your team doesn't feel comfortable doing either and see it as a drag they will resist using them or will implement only the bit they can do quickly and find an excuse not to use the other methodology.

Online you can find multiple examples of how to use both BDD and TDD, but they are often simplified and don't deal with more complex and frequent problems such as populating databases, generating testing data, making sure the acceptance cases run on multiple browsers, brittle tests, etc.

Don't get discouraged because you don't get results as quickly as you thought you would. Implementing BDD and TDD is going to take time, but it is very, very, very important (can't stress it enough) to make sure that writing tests is as natural for your team as using the turn signal when you drive. You just do it, don't think if it is worth it or not, it is automatic.

Many of these problems in your path, find you will… mitigate them you shall...

What’s the secret? Training, practice, exercise and...then more practice. There are great books to help you follow the process and tooling is essential.

The right tool for the job

In my experience, one of the main reasons developers get discouraged to write tests is poor tooling.

I think we are past finding testing frameworks and runners, still we have areas that are not always covered.

Testing hooks & metadata

Most frameworks you may choose to work with will have some kind of hooks. Before tests, after tests, before all tests, etc.

Being able to tag tests and identify which ones are using the database, is another great feature to have.

RSpec is a great tool to take a peek at what kind of features could be useful for your current need. Probably there are similar libraries with the language you work with that implement the same or similar ideas.

And if not, why not collaborate with the community and build some?

Fake domain data

It is very common to need dummy data to support your scenarios. They can be useful for acceptance testing and for unit testing as well.

Having an easy way to generate fake data is really important. It will simplify how you write your tests and also give you the feeling that you are talking in domain terms, making much easier to understand what the test is about and implement the code.

Libraries like Factory Girl, FsCheck, AutoFixture, GenFu are great examples to know what to look for.

Not only you can generate good customers, bad customers, etc., but you can also generate multiple cases to test and, even further, why not look into some automatic generation.

Databases

Working with databases should be simple and straightforward: loading data before the tests, cleaning after, restoring the schema (if you have one) to a certain point, and populating.

Combining database manipulation with hooks and data generation will give you lots of power to set up scenarios in an easy, painless way.

The importance of NOT being brittle

Let’s imagine we have mastered the tools and the learning curve. Now we have a new foe that threatens our Ninja skills and may bring our confidence to the floor: Brittle tests.

Tests have to be maintained and kept running green all the time, otherwise defeats the purpose.

You want your tests to be (somehow) resilient to changes in the code. This is a more advanced problem and here are a few tips to check before we can talk about balance.

Isolation

Avoid assuming a particular state that you don't control. Tests may run now but may not run in the future.

Any state needed to make the test pass has to be set up before the test runs and torn down after the test finishes running.

Implementation coupling

Tests should be about inputs and outputs, not about how they are implemented. Testing a method that queries the database by mocking the way the query is implemented is dangerous. Similarly, testing with a very small set of data may lead you to the wrong conclusion.

You will be better off focusing on Properties Testing. Libraries like FsCheck and Rantly can help you enforce pre-conditions and post-conditions and inspire you to look for other ways to make your testing robust.

Mocking the mock

Tests should work for you, not the other way around. If you find yourself creating more code in order to make your current code testable that deserves some attention.

Whenever you postpone testing complexity and replace it with a mock remember that the same complexity will have to be tested later.

Creating interfaces to improve reusability is a great idea, however, make sure you need it.For example, abstracting the repository pattern may not be always a good idea.

Tools galore

Though there's a plethora of tools to choose from, they will not always come in the exact shape and color you need them.

Don't get discouraged! Learn from it and build your own.

For example, writing domain specific languages to help you test will ease the pain of repeating common scenarios again and again. The investment will pay off.

Finding balance

Now our team has overcome the hardships of testing and is quite confident implementing both TDD and BDD. They can do them with their eyes closed while dancing the Macarena.

So what's the right balance? For me it is confidence.

Do I need to write tests for every domain model, every single scenario, every api call?

Well...it is up to you.

I lean on the acceptance side often to ensure everything works as expected.

If you have a senior team then perhaps you can relax a bit more and choose which unit tests should be implemented to find a balance between BDD and TDD that you feel comfortable with.

If you don't see crystal clear that writing one test will imply that the other part is working, then don't skip anything.

Even for acceptance test if you find features that are really similar to others and strongly believe that implementing test scenarios won’t be necessary because your unit/integration test already covers that, go ahead and skip them.

It is a fine line, but the key is confidence.

It was meant to be used as an interface to a collection, but what I have seen more often is that it becomes an abstraction to the data layer or ORM framework.

Not so long ago I did a presentation on Who killed object oriented programming, and I mentioned the Repository implementation as one of the culprits.

So what's so bad about it? What can we do to improve it?

I have a counter-proposal: What if we don't need it at all?

Repository overpopulation

Have you ever felt that the Repositories in your code replicate at night? You remember that when you started the project you had one or two, but now the number has grown to almost one per data model.

I remember starting with something like this:

1
2
3

public interface ICustomerRepository {
  IEnumerable<Customer> GetCustomers();
}

And then I needed to add queries such as find by Address, find by Id and find which customers have pending invoices:

1
2
3
4
5

public interface ICustomerRepository {
  IEnumerable<Customer> FindByAddress(Address address);
  IEnumerable<Customer> FindById(CustomerId id);
  IEnumerable<Customer> FindWithPendingInvoices();    
}

Once one was completed, I replicated the recipe for each model: Invoice, Car, Chair, etc.

Eliminating the repetition

Maybe we don't need one per model. What if we could use a generic class?

1
2
3

public interface IRepository<T> {
  IEnumerable<T> GetAll();
}

Now that's slightly better, but what happened to the queries?

Extracting custom queries

Instead of adding queries following the business rules and modifying the Repository each time, why not use IQueryable instead? That way we can combine the results with further queries.

1
2
3

public interface IRepository<out T> {
  IQueryable<T> GetAll();
}

Then we just need to combine the filtering and ordering after:

1
2
3
4
5
6

var customers = ... // instantiate a concrete IRepository<Customer>
  
return customers
    .Where(c => c.Address != null)
    .OrderBy(c => c.Name)
    .Take(100);

Common queries

We can easily put this logic (if it's really commonly used) into an extension method (or another class) to avoid repeating the same query and to capture complexity.

1
2
3
4
5
6
7
8

public static class CustomerQueries {
  public static IQueryable<Customer> WithAddress(this IQueryable<Customer> customers) {
    return customers
        .Where(c => c.Address != null)
        .OrderBy(c => c.Name)
        .Take(100);
  }
}

This would allow us to reuse the query when needed:

1
2
3

var customers = ... // instantiate a concrete IRepository<Customer>
  
return customers.WithAddress();

Abstracted abstraction

We’ve done a great job (pat on the back) so far! Now it’s much simpler...so simple that when we look at the implementation, we see we are just using the ORM (NHibernate, Entity Framework, etc.) to return the main collection and nothing else.

The result in this case is that the Repository pattern is abstracting us from another abstraction! What are we gaining from this?

Why not just use the ORM? Are we planning on changing ORMs in the middle on the project?

We should take advantage of all the power that the ORM is giving us. We don't want to have to copy the ability to do joins, sorting, etc.

Weeping...is cathartic...

What about testing?

Another reason to introduce the Repository could be testing.

But what are we going to test? Should we be testing the method GetAll?

Are we planning to mock IQueryable? Or, even further, mock all the methods that come with the ORM session?

The logic is mostly in the queries or, for example, in controllers doing queries in a web application.

Unit tests won't work in this case. We don't want to depend on which methods are used or in which order they’re used, so we need to make sure the inputs are defined and write assertions on the outputs enforcing the pre- and post-condition.

This case calls for integration tests (small tests setting up the database before and cleaning it up after) to help us ensure it works as expected.

Summary

Make your life simpler and your work more enjoyable. Abstractions should make the code easier to read. If that is not the case, then it is time to reflect and review.

Perhaps it is a bit late to change the project we are working on right now, but next time let’s make sure we give quite a bit more thought to using the Repository pattern.