Stephan Schwab

Software development and farm life

Archive for March 2011

Water is essential for new pasture during dry season

leave a comment »

For the horses we need a new place to stay. So far I had rented pasture but as most subsistence farmers do not invest in any kind of irrigation system, all the available pastures have fallen dry and there is nothing to eat. Where the horses currently stay is a nice place with easy access but we had to cut and carry the food for them.

Now an opportunity to acquire some land has shown up and we used last week to clean some of it to turn it into a new pasture. As everywhere else the land has been fallen completely dry despite the fact that there is water coming out of the ground in several places.

We followed one of the little creeks to find the source and built a small retaining wall.

DSC 0041

Then we dug a larger hole so that the water can accumulate and build up pressure for the irrigation system.

DSC 0062

Currently water levels of all these little creeks are at a minimum as we are at the height of the dry season. The good news is that a creek that still has water at this time of the year is one that has water every single day of the year. So it simply becomes a matter of distributing the water to where it is needed. Further down it will join the creek again but before that the grass on the pasture will be irrigated.

DSC 0072

So yesterday we tried for the first time with a hose and a garden sprinkler. The pressure is very low at the moment but that may be because the water level behind the wall is not that high yet and we had leaves clogging the pipe. We need to install some kind of a net to prevent stuff from entering the pipe.

The very same creek – just a few meters below the pasture – has formed a deep pond and a little waterfall. I’m thinking about using a hydraulic ram pump to use the kinetic energy of the water to move it up. That pump may provide enough pressure for larger sprinklers that can throw water over a significant distance.

DSC 0084

Another idea is to use a low pressure system and irrigate drop by drop using one of these hoses with many little holes in them. These get buried into the ground and water simply flows out of the hose over its full length – drop by drop. That may work very well as the pasture is sloped.

I guess we will have to experiment a bit. At the very least we now have some irrigation system to start with and I expect the grass to become green and start growing over the next few days.

PS: For those who have been reading my stories about the rainforest farm before… No, the issues are still ongoing. I plan to tell the story when there is a result. At present nothing gets decided because the competent authority is being dismantled and is without leadership until the replacement authority has started to take over. It’s a political thing.

Written by Stephan Schwab

March 30, 2011 at 11:10 pm

Posted in Farm Life

Validation rules for form input in Acceptance Test Driven Development

leave a comment »

A lot of business applications present forms to the user and there is always the need to validate user input into these forms. Should we test validation of form input in a Cucumber feature when practicing Acceptance Test Driven Development?

To me Acceptance Test Driven Development is not about testing. Based on that testing validation rules is doing the wrong thing for the right reason. Of course you need to specify your validation rules somewhere and test them. However, there are many different tools in a team’s toolbox. Some are for a very similar purpose but as in the physical world there is a reason why you keep all of them in your toolbox and not rely on a single tool for every job.

Unit testing a validator class

Regardless of the programming language you are using you can probably create something like a validator class – basically some piece of code where you keep all the validation rules. It should be easy to test drive that and then you just have to make sure you reuse it in all the places where you need validation of input.

Tell a good story and still show that input is being validated

In your Cucumber features you should always tell a good story based on what your customers tell you. You should use their language and not say that a first name in a form cannot have special characters like $%^& or similar. Real end users don’t care about that kind of detail. They care about that the application works and doesn’t crash.

Still there may be a need to prohibit the input of those special characters for some valid reason. If that is the case, then it becomes part of your acceptance criteria and it should be shown in a Cucumber feature. After all Cucumber features are our primary means of communication and these .feature files are also documentation that may be required for regulatory reasons.

On the other hand you should not repeat in your Cucumber feature what the unit tests are already doing. Keep it short and keep it to the point. You may tell a good story in the happy path scenario and then show that input gets validated in another scenario. I think it is enough to say that “invalid input will be rejected” in most cases. If you are required to show explicitly what “invalid input” is, then you may show an example in a “When” step.

Written by Stephan Schwab

March 21, 2011 at 12:06 pm

Acceptance Test Driven Development changes how you organize your project

leave a comment »

Anyone who sets out to develop software does so with a specific motivation. Common motivations are to reduce the cost of some business process, to increase revenue by being able to serve more customers or to create something to sell in the case where the software itself is the product.

Software development is expensive and it takes quite some time to create something meaningful. Some people see how fast you can use software to solve a problem, but rarely have an opportunity to see what it takes to build that software in the first place. That frequently leads to wrong expectations.

Risk, Return on Investment

Because of the cost and time it takes to develop software it seems a good idea to look at the risk involved and understand when there is a return on the investment being made. Whenever some activity takes a long time the risk increases because more and more things can change. If something takes just two weeks, then you will likely be done before something changes. If it takes four months or a year, then almost everything can change. It is simply more likely, because people have new ideas, competitors are not standing still, new things get discovered, etc.

That means the earlier your investment into software provides something in return, the less risk you have. You may also have covered potential losses to some extend, if you need to stop unexpectedly.

At least that’s the theory. Let’s see what we as software developers can do to make it work.

Take on first: High Risk, High Value

Let’s assume you want to build an application that is a provider of data for an established backend system. Let’s further assume that your main motivation for building said application is to provide end users a better experience than what they are used to.

Where would you start?

Would you start to work on the user experience, as this is why you are starting the project in the first place?

Or would you start with the integration to the existing backend system?

To answer the question we need to look at risk and value. The motivation we have for doing the work and spending money may not be our best guide here.

If we were starting our project with the user interface, we would certainly be working on the item with the highest value to our stakeholders. After all our stakeholders are paying for precisely that and we want to please them and provide as fast as possible something they can use.

But then if we were starting our project with the user interface, we would incur the risk that we will get to the integration to the existing backend system very late in the project and it may not work very well or not at all, because we assumed a few things that led to a certain design in code – and then it may turn out that these assumptions were wrong. If that happens, there would be the user interface our stakeholders had be waiting for but the application cannot be put into production until the integration to the backend system has been fixed.

So the item with the highest risk is clearly the integration to the backend system. There will be no return on investment at all, if that part does not work. After a 6 months project that produced the perfect user interface the pressure on the team will be extreme and probably the same stakeholders who have been very happy so far will be extremely upset once it turns out that the whole investment is likely to be a total loss unless the integration gets fixed.

What about the value?

After considering the all or nothing nature of the integration to an existing system the value of the integration story is probably much higher than the story about the user interface.

How Acceptance Test Driven Development helps

Whenever you start a software project the first question should be:

What is the criteria used by the stakeholders to accept the result of the project?

In my example that leads to a generic Given/When/Then like this:

Scenario: Our ultimate goal for the project
	Given an application with a well designed user interface
	When the end user enters all the data needed by the backend system
	Then the backend system will receive all the data

As we want our Given/When/Then steps to be executable, we now have to find out what is the smallest thing that could possibly work and allow the application to pass the test.

For the Given this is relatively easy. We just need an application with some user interface. It does not matter at this point that we do not really build something specific.

For the When we can start out with a simple form with just one element (say a text field) so that we can enter some data and trigger some simplistic code that creates a file, calls a web service, opens up a TCP/IP socket or whatever the interface to the backend system happens to be. At this point we are not interested in completing the work but instead we want to figure out the details. Instead of relying on guesses – as educated they may be – we write some real code and run it.

For the Then we use the backend system to find out about the data that we sent to it during execution of the When step. Maybe there is a user interface we can access using some automation tool. Maybe there is a database we can connect to and run a query. There might be a web service or something else.

So to complete our very first story we need to do as much as is needed to get some data from our application into the backend system and be able to verify the successful reception of that data.

Make it richer

Now that we have a “walking skeleton” we can work on making the application do more and more and become more feature complete. Each step of the way we want to prioritize our work based on value and risk. Always think about which story enhances the application’s usefulness more when you have to decide which one of two stories is more valuable.

In the case of the application that captures data and provides it to a backend system your nice to have stories are clearly those that enhance the user experience. At least as long as you have gaps in the data you send to the backend system. It does not really matter how your stakeholders perceive this. As a development team you need to educate and explain how you use their money in a responsible and goal oriented way. Everybody needs to understand that we will get to everything – some day – but we need to work based on the real acceptance criteria. The one and only criteria that really counts at the end of the day is working software.

So in the example there is nothing wrong in building a front end application that is nothing more than a bunch of text fields but does send the right data in the right format to the backend system. Next iterations the team can enhance the user experience by using drop-down lists to choose from a range of valid inputs instead of typing in the value and so on.

Dependencies and interaction in the user interface

In many applications the user gets asked a few things and the answers determine what he will see on some screens later on. A web site to buy car insurance may want to ask details about the spouse, if the customer has indicated that he is married. Such behavior is simply an enhancement to some other story and it does not prevent the team from building a “working skeleton” that works from end to end.

Backend systems that want all or nothing

Say your existing backend system absolutely needs a lot of data and will not accept the input from the “walking skeleton” until it is complete. Instead of going to all the trouble to build all the stuff you need to provide that data, you can simply fake it.

There is nothing wrong in picking one example of valid data and another example of invalid data and simply hardcode whatever is needed to pass it along. Just make sure you have stories for the real thing and put them into your backlog so you won’t forget.

Written by Stephan Schwab

March 19, 2011 at 4:03 pm

How to deal with sending email in Acceptance Test Driven Development with Cucumber

leave a comment »

At times one needs to think a bit harder about how to test something when it goes beyond interacting with web pages or other types of user interfaces. That is usually the case when one system interacts with another. I’d like to share one such case and explain my solution to the problem.

Given there is an application that allows users to register and then they get an email that contains a link that needs to be followed to confirm the reception of said email.

So that states the problem. There are several ways to solve it.

a) use some external mail service and access it via POP3 or IMAP from your Cucumber scripts

b) configure your own internal mail service with mailboxes and then access it via POP3 or IMAP from your Cucumber scripts

c) make the application under test be test-aware and have it write emails to a file instead of using the SMTP transport

Originally I was using MRI Ruby and used approach a). My external mail server was GMail and I accessed it via secure IMAP. For that I had written a simple class that logs into GMail, finds the email of interest, reads the body to find the URL for the link to be followed and then cleaned up by deleting the email. That was little effort and worked very well.

A while later I switched to JRuby because I wanted to use the Maven plugin for Cucumber to run all my acceptance tests as part of the Maven build. The application under test is written in Java. My ultimate goal was to deploy a well tested artifact directly from Maven so that I can start doing continuous deployment to production.

After switching from MRI Ruby to JRuby I noticed that I was now unable to connect to GMail due an issue with the validation of SSL certificates. I tried shortly to tell JRuby to accept whatever the other site presents but then I started to rethink my whole approach.

Why should my acceptance test depend on an external service like GMail? A service I don’t control. A service that can be down in the middle of something important and urgent.

Sure I can turn my laptop into a mail server – but do I need to?

I’m working on Mac OS X and there is already Postfix as MTA (message transfer agent) installed. I was using it already to send email from the application. As I have extensive experience in running mail servers from “a former life” (I used to run an Internet Service Provider in the late 1990s) that should not be problem. Quickly I typed sudo ports install cyrus-imapd and then it dawned me that there has to be an easier way than to set up a full-blown email service on my laptop.

No need to test external systems

There is no law that says your application always needs to do the real thing or talk to any external system for real. All we want is the acceptance criteria to be met and do that in a test that is reasonable enough to show that the application is behaving correctly. In my case it was not at all about proving the ability to actually deliver an email to a place beyond my laptop.

What I did

In the Java code a MimeMessage gets prepared and then handed over to JavaMail for delivery. The delivery takes place by calling Transport.send(message). That was my opportunity. It is a simple method call and who said I can’t call something I created and in there I can either send the email by calling Transport.send(message) or write the full email to a file …

Luckily JavaMail already has the ability to print a message to an OutputStream. So with a simple message.writeTo(new FileOutputStream(messageFile)) it ends up in a text file.

On the Ruby side in my Cucumber script I use filename = "/tmp/test-#{expected_recipient}" to look for emails in files. Under test my application writes files like /tmp/ The rest of my already existing Ruby code that looks for the confirmation link in those emails works unchanged.

Further I was able to remove a wait period from my script. That wait period was necessary because the delivery of an email to an actual mail service (much so when using an external service) can take a while. Now all my scenarios that deal with email run as fast as possible without any delay.

Build applications that are test aware

As this example shows sometimes it is necessary that the application under test cooperates and is aware of the fact that it runs under test. As I mentioned I am using the Cucumber plugin for Maven. This runs Cucumbers during the integration test phase. In the pre integration test phase Maven starts up Tomcat and deploys the application to it. I let the application know that it now runs under test and that tells my IoC container to use different implementations at the edges. One is the one described here.

In production nothing gets changed at the edges and the application talks to the real external systems.

But isn’t it dangerous to change the application while under test?

Yes, it can be. But in my opinion it is much more dangerous not to have clear acceptance criteria and not test enough. There is some remaining risk which can be mitigated by not deploying new code to a large server cluster all at once but instead roll out new code gradually. There have been articles about large web sites where such a gradual rollout is being used successfully.

Written by Stephan Schwab

March 15, 2011 at 10:13 pm

Don’t tie Cucumber features 1:1 to stories

with 3 comments

When practicing Acceptance Test Driven Development one may think that there is a one to one match between a user story and a Cucumber feature. Initially that may seem to be a good idea but you get into trouble, if you actually want to preserve some kind of paper trail.

Here is an example:

Let’s assume your team numbers user stories and then creates Cucumber features that also use the story number in the file name and within the feature file. Doing so establishes a one to one relationship between story and Cucumber feature.

After a while the thing described in some initial story evolves by means of other stories. You will certainly create new Cucumber features, faithfully following your pattern, to describe the new functionality.

What about the steps you used in the initial feature?

You may find that some of these steps don’t apply because they don’t describe sufficiently the new functionality. So you create new steps.

Over time you will have many steps that are very similar and only differ in minor details. But they all talk about the same thing.

Because you want to maintain a “paper trail” you don’t change older features, as that would break the one to one relationship to the stories they are based on.

Using a 1:1 relationship between Cucumber features and user stories and maintaining that is an anti-pattern that should be avoided. It seems to appear frequently together with UI centric features that focus on how the application is to be operated. Both lead to brittle tests that are increasingly hard to maintain.

Written by Stephan Schwab

March 11, 2011 at 10:46 am

Smells in Cucumber features

with one comment

As with other forms of source code there are code smells in Cucumber feature. They should be avoided.

Clicking, filling out forms, detailed handling of the user interface

Creating a Cucumber scenario where you describe in detail how the application’s user interface will be used is missing the point. Acceptance Test Driven Development is not about testing how something works. It is about creating a specification of expected behavior and outcomes from the outside in before the application’s code is written. You should express in a Cucumber scenario what the application should do and not how it will do it.

In some cases the existence of such prescriptive scenarios may even point to some organizational dysfunction as the root cause. Maybe the team gets handed very detailed descriptions of how the application should look like and work by a group outside the team and the team is expected to create exactly what has been handed to them on paper. The team will want to test well and so they end up writing Cucumber scenarios that test the user interface as it were record and play back.

The danger here is that the whole organization misses an opportunity and spends a lot of money on a wasteful activity. Designers say that form should follow function. If you create the form before you clear on the desired function, you limit your options too early. In the end smarter or simpler solutions cannot be found because the how has already been defined. Even worse. The how has been defined by people who probably don’t know much about what it takes to write the code for it. So instead of working on a solution to the original business problem the team is working on implementing a very specific user interface and is likely to take shortcuts elsewhere because time runs out. A likely candidate that may be neglected is the business logic. It may take quite a while for someone to notice that because the applications looks as expected and asked for, everybody is happy and only after the application is in production the shortcomings and missed opportunities will be seen.

Scenarios without a “When” step

There may be cases where a scenario without a “When” step is justified and valid but in general a missing “When” means that there is no action. Rarely applications just sit there.

I’ve seen this smell in combination with stories that only ask for a specific user interface to be present. The story does not ask for any action to happen but merely says that x, y, and z should be on the screen. That leads to a scenario with a number of “Then” steps immediately after one or multiple “Given”.

Again this may highlight the same organizational dysfunction as mentioned above. The team should ask the product owner and stakeholders what the real business value is and if necessary educate them about the opportunities that everybody will miss out on.

Another possible root cause for such scenarios and stories may be that in the organization there is little trust in the abilities of the development team so business experts try to be very specific and prescriptive.

Written by Stephan Schwab

March 9, 2011 at 10:04 am

Benefits of Acceptance Test Driven Development

leave a comment »

Traditionally testing has been an activity after development was done. It seems logically correct to test something after it exists and so the cycle has always been write a specification of some sort, then program it and once a programmer says “I’m done” a tester will verify that the code does what is expected.

With Acceptance Test Driven Development that cycle changes.

Similar to what you do when practicing TDD (Test Driven Development) by using Acceptance Test Driven Development you write the tests before the code. Instead of writing a specification as a static document, you create an executable specification that will run the code to be written and that can be refactored and refined.

Acceptance Test Driven Development changes the work of testers. Not longer are they at the end of the cycle but they are moved to the beginning and in fact they can lead it or at least be of great help. If your team is small and you can’t afford dedicated business analysts, a good idea might be to have smart testers help out as analysts and work closely with end users or those in your organization who own the vision for the product being developed.

It is not about testing at all

Although the word “test” appears in the name the practice of Acceptance Test Driven Development is not at all about testing. ATDD is another tool in the box to facilitate goal oriented communication and get everybody on the same page. It is about defining in a non-ambiguous way what is desired.

By using a tool such as Cucumber there is a living document – the feature file – which is shared and used by every member of the team. As this document is written in human language (Cucumber supports features written in English, German, Spanish and many more) there is no barrier of access for anyone.

Focus is on the problem not how the solution looks like

To really reap that main benefit of Acceptance Test Driven Development it is important to write features in a way that they really describe the business problem to be solved and not how the user interface of the application will be used. That is usually the hardest part of using Acceptance Test Driven Development and it takes time to learn that important skill. Teams new to this should consider bringing in outside help and retain a consultant for some time.

No more outdated documents

Another benefit is that there are less documents in the true sense of the word. Cucumber feature files are source code and they live right next to the other source code in your version control system. And there are definitely no dead, outdated documents that are dragged around but nobody really cares about them.

Smaller team size and no more throwing artifacts over the wall

When practicing Acceptance Test Driven Development the whole team collaborates and communicates. That prevents silos from building up and teams may also be smaller. In small teams there is no culture neither a need to hand over artifacts with ceremony attached to it. People just work together naturally.

Teams can be smaller because there are only two important things. The executable specification (the Cucumber feature file) and the working software that passes that specification. To create both you only need a very limited number of people. It needs one person to describe what she wants, another person to put that into an executable specification (a tester writing Cucumber feature and step definitions), and then a programmer or a pair of programmers to make it happen.

Written by Stephan Schwab

March 8, 2011 at 4:16 pm


Get every new post delivered to your Inbox.

Join 259 other followers