Just in Time details – A refresher

A backlog can contain user stories. And these user stories are just the three C’s as Ron Jeffries stated.

• Customer
• Collaboration
• Confirmation

It is written by the Customer and it is so little text that you are forced to Collaborate with the customer because otherwise you do not know what to develop.
The Confirmation enables a team to make a reasonable estimate of the user stories and so we come up with a estimated backlog.

A good thing is that the user stories naturally encourage us from adding requirement details at an early stage. Once the PO selects user stories for the next sprint the necessary details can be added Just In Time, like UI, data specifications, business rules, business process flows etc. People need time to add these details, not because the actual writing or describing takes time, but because people need to think about what they want. It is partly a creative process, partly a discovery process and this takes time!
Not all requirements should be written down in full detail, but just enough to have a good start the next sprint! Next to adding details to the scheduled user stories the backlog should also be improved by for example adding new stories, splitting stories from existing epics and estimating any new stories.
So people of the team need to start thinking about some details and adding the details to the selected user stories for next sprint during the current sprint. This of-course interferes with their activities in the current sprint, but the benefits of preparing are often higher then the losses due to e.g. task switching.

In order to start the information transfer to the team members early on, half way the sprint a requirement workshop can be organized to share and learn about the user stories scheduled for next sprint. The result of this workshop is a better mutual understanding within the whole team about what to build and what can be improved prior to the sprint planning meeting. Such a workshop should also result in a set of acceptance examples of how the PO wants to verify that a user story is build in the right way.
An important benefit is that the end result of the user story details are better because the knowledge of the whole team is used. A great side effect is that because the team is involved and contributes to the requirements and therefore the direction of the product to be developed, their responsibility and motivation is increased.

So now the sprint planning will go smoother, concurrent development during the sprint is much easier to do and WIP is under control.
In Scrum btw we expect a team to spent around 10% of a sprint grooming the backlog and preparing for the next sprint.

But isn’t this mini waterfall? No! In waterfall all requirements are detailed before development starts. But even if it was waterfall, so what! Is the goal to not do waterfall?

Writing a BDD DSL in Scala

One of my favourite BDD frameworks is easyb. I really like the dsl for user stories. In a previous post called Easy Requirements by Example I discussed how easy and clear this dsl can be.

For Scala I would also like to have a dsl just like the one of easyb. Writing a dsl in Scala is real easy, not as easy as in Groovy, but easy enough. So I decided to see how fast I could write a story dsl in Scala.

So, I need to be able to write things like the following

   given ("a blogger with a blog") {
    	val blogger = new Blogger("Mr Blog", "mrblog@blogger.com", "passwd")
    	val blog = new Blog("blogTitle", blogger)

		when("mr blog writes a new post") {
			blog addPost ("post Title", "post Text");
		}
		and
		when("mr blog publishes its post") {
		    blog publishPost
		}
		then("the post should be publised for reading") {
			blog.published shouldHave "post Title"
		}
	  }

The words given, when, then, and, shouldHave are part of the dsl.
The story dsl words are defined by a curried function. They have a explaining piece of text as the first argument and a code block as the second argument.

See below the definition of given

  def given(text: String)( codeBlock: => Unit ) = {
	  codeBlock;
  }

Because given is a curried function you can pass in the arguments one at a time. And when you pass in one argument you can choose to use curly braces instead of parentheses. As you can see in the above example, the given function has the rest of the story as the second argument within curly braces. So, the when, then, and form the codeBlock argument.

Here is the definition of the other methods

  def then(text: String)( codeBlock: => Unit ) = {
    codeBlock;
  }
    
  def when(text: String)( codeBlock: => Unit ) = {
    codeBlock;
  }
    
  def and(text: String)() = {
  } 

… Yep this is really simple!

Because the codeBlock parameters are so-called “By-name-parameters” the codeBlocks of the functions are only evaluated when the given method evaluates it’s codeBlock! Also because closures in Scala see changes made to the free variables outside of the closure itself, you get the sequential execution ordering of the story.

The only thing that is left is the shouldHave word. As you might have guessed this is just a simple implicit conversion. To have free integration with IDE’s and other tools I choose to use JUnit as the underlying framework. So all the dsl vertification words are mapped to JUnit asserts as you can see below.

  implicit def shouldHave(l: List[Any]) = {
	  ShouldHave(l)
  }

case class ShouldHave(i: List[Any]) {
    def shouldHave(j: Any) = {    	
    	assertEquals(j, i.find( _ == j))
    }    
}

You can use the dsl in your JUnit test like this

@Test
def bloggerSpecification() = {

given ("a blogger with a blog") {
…..
}
}

You can imagine that you would like to execute a story multiple times with different argument values. Lets say that you would like to execute the story with multiple post titles. A little extension of the dsl made that possible. I introduced the words testcases, addCase and execute_testcases_with_specification.
See below an example

    testcases {
    	var postTitle: String = null;
    	
    	addCase { postTitle = "title 1"	}
    	addCase { postTitle = "title 2"	}
    	
    	execute_testcases_with_specification {
    		given ("a blogger with a blog") { 	
    			val blogger = new Blogger("Mr Blog", "mrblog@blogger.com", "passwd")
    			val blog = new Blog("blogTitle", blogger)		   
		        
    			when ("mr blog writes a new post") { 
    				blog addPost (postTitle, "post Text");			   
    			}
    			and
    			when ("mr blog publishes its post") {
    				blog publishPost
    			}
    			then ("the post should be publised fo reading") {
    				blog.published exists(_.title == postTitle) shouldBe true			
    			}		   
    		} 	
    	}
 

What you see is that there are two test cases, each specifying a different value for the postTitle. The story is executed for each test case where the free variables are changed according to the test case at hand.

In order to make this work I stored all the test cases in a list. Then for each test case I first evaluate the test case. This sets the free variables of the story closure. Next I evaluate the story itself.

Again the code is really simple as you can see below.

object TestCase {

  var codeBlocks = List[() => Unit]()
  var scenario: Any = 0;
  
  def addCase( codeBlock: => Unit) = {
	  codeBlocks = codeBlock _ :: codeBlocks
  }
     
  def execute_testcases_with_specification( scenario: => Unit) = {
    codeBlocks.foreach( codeBlock => {
      codeBlock();
      scenario;
    })
  }
  
  def testcases( codeBlock: => Unit) = {
	  codeBlock
  }
}

If you made it this far in the post… what do you think of this approach?

User story driven performance testing

Quite often performance testing is only done after the system is developed and is in it’s acceptance phase. Of course this can give you some unpleasant surprises. You would like to get feedback on performance issues as quickly as possible.

We could tackle part of this problem by doing performance testing each iteration and by making performance testing part of the daily or continues build. To make the test results most valuable, the test environment should resemble the production environment as much as possible. I know that it’s very hard to realize this especially in big projects at big companies. But even if you cannot have a representative environment, doing performance testing each iteration can give you some good insights into performance trends during development. If some piece of functionality is getting slower and slower it could indicate that there are performance issues. Having insights in these trends gives you the possibility to investigate these possible performance issues early on while fixing them is still cheap.

JUnitPerf is a library for decorating JUnit tests to measure the performance of functionality contained within existing JUnit tests. You can write TimedTests that test if a JUnit test finishes within a certain time. You can also write a LoadTest that lets you measure the elapsed time under concurrent use. Because it is based on the Decorator pattern you can easily combine load en timed tests to create more complicated ones.

Using JUnitPerf can give you trends based on written JUnit tests. But a JUnit test is not that suitable for performance testing. A JUnit test fixture can have a number of various tests including expected failures etc. What would really be interesting is measuring performance of functionality that is valuable to a system user. You would like use your user story scenarios not only for acceptance testing of functionality but also for performance measurement.

The idea is to use a BDD framework like easyb for writing your acceptance test scenarios for a iteration as I explained in Easy Requirements by Example. The scenarios are complete pieces of user valued functionality and so are a perfect candidate for performance testing.

It would be great if you could write something like this in easyb for measuring performance of individual steps;

performancetest {
given “scenario X”, {
Scenario x = new Scenario(“X.groovy”);
}
when “load is generated by 10 persons”, {
x.load 10
}
then “measure individual step performance”, {
x.measureSteps
x.start
}
}

or the following for a timedtest under certain load;

performancetest {
given “scenario X”, {
when “load is generated by 10 persons”, {
x.load 10
}
then “response time should less then 3 seconds”, {
x.start
x.responseTime.lessThan 3
}
}

or just for a timed test as

performancetest {
given“scenario X”, {
when “load is generated by 1 person”, {
x.load 1
}
then “measure end to end performance”, {
x.measureEndToEnd
x.start
}
}

I am currently working on getting this done in easyb. I’ll write about it in the next weeks.

Easy requirements by example

There is this fun framework called easyb http://www.easyb.org/ that could be used to make you stories or requirements by example executable in an easy way.
In the article ‘Introducing BDD’ http://dannorth.net/introducing-bdd Dan North discusses BDD and uses the following user story for explanation.

Story: Customer withdraws cash
As a customer,
I want to withdraw cash from an ATM,
so that I don’t have to wait in line at the bank..

Well, now let’s assume you are in a meeting discussing this user story and as a good team you ask the customer to give some specific examples of it. During the discussion you are of course helped by the testers who help the team also focus on ‘things the system should not do’. At the end of the meeting you have a good understanding of the user story and have a couple of written examples such as the one shown below.

scenario Account is in credit
given the account has 10 dollars in credit
and given the dispenser contains 1000 dollars
and given the card is valid
when the customer requests 5 dollars
then ensure the account is debited and now contains 5 dollars
and then ensure cash is dispensed from the dispenser and the dispenser now has 995 dollars

It would be great if you could translate this easily to an executable specification so that you could start developing your Java or Groovy code against it. The good news is that you can do this easily with easyb. You could write your test as follows:

scenario “Account is in credit”, {
given “the account has 10 dollars in credit”, {
//do some stuff here
}
and
given “the dispenser contains 1000 dollars”, {
//do some stuff here
}
and
given “the card is valid”, {
//do some stuff here
}
when “the customer requests 5 dollars”, {
//do some stuff here
}
then “ensure the account is debited and now contains 5 dollars”, {
//do some stuff here
}
and
then “ensure cash is dispensed from the dispenser and the dispenser now has 995 dollars”, {
//do some stuff here
}

}

This almost the same as the text from the scenario and is easy for non technical people to read and understand! Once you have this you can start developing and could arrive at something like this:

scenario “Account is in credit”, {
given “the account has 10 dollars in credit”, {
accountInCredit = Account.create(10)
}
and
given “the dispenser contains 1000 dollars”, {
dispenser = Dispenser.create(1000)
}
and
given “the card is valid”, {
card = Card.create(accountInCredit)
card.enabled = true
dispenser.insertCard card
}
when “the customer requests 5 dollars”, {
dispenser.requestCash 5
}
then “ensure the account is debited and now contains 5 dollars”, {
accountInCredit.amount.shouldBe 5
}
and
then “ensure cash is dispensed from the dispenser and the dispenser now has 995 dollars”, {
dispenser.amount.shouldBe 995
}
}

Well…. you probably would not arrive at something like this in a real system but this is just an example…
You could use this for unit testing, using the groovy build in possibilities of mocking and stubbing and if that’s not enough you could use Java frameworks like EasyMock, and DbUnit to name a few.

But I see more value for this on integration testing your system and creating a suite of acceptance test scenarios for a iteration. You can easily mail it, print it to discuss and its easy to come up with more test cases once you have a example.