Functional Test Driven Development

Requirements are always handed out in English. But I think English is a tricky language. For example we I say "The kid ran when the dog barked" it could mean that the Kid started running because the dog barked or the dog started barking when the kid ran. When a simple statement can lead to many different interpretations think about the requirements in complex systems. Usually in such systems, when the developer codes based on his wrong interpretation of the requirement /story, it comes up as bugs during BA/QA signoff. Developers now spend the same or even greater amount of time fixing the bug. In this scenario we can’t blame anyone. As a solution to this it would be great if the developers could have their interpretations checked now and then. And the solution we came up with, in our project, was to develop automated functional tests before development.

Automated functional tests were a boon to the developers in the following aspects:
1.They act like a measurable form of requirements.
The developers were able to visually see how far they are from getting the story done. Also when a different pair started working on the story it made it easy for the new pair to continue from what was left. And also Functional tests helped the developers to know when they are done with the story.
2. They correct the wrong interpretation sooner than later.
When the developer tries to run the automated test after he completes a task the test would fail if his interpretation of the requirements were different from that of the analyst.
3. They don’t lead to multiple interpretations.
These test are straightforward. Either the test passes or fails and the developer cannot move on to the next step until the code meets the expectation.
4. It reduces the amount of bugs that can be found. And in turn reduces the bug turnaround time.
5. Functional tests are too detail.
Even the simple things like formatting cannot be ignored.

It’s really nice to have functional tests ready while developing isn’t it? Yes, But it is not a very easy task. As there are advantages, there are many disadvantages too to have the functional tests written before development on the story starts.

1.There may be a lot of unknowns as the design is not yet complete on the story.
2.When the design changes during development the functional tests have to be modified. This happens most of the times and the analysts will be repeatedly changing the test script based on development changes.
3.The main disadvantage I see is that, as the tests are written based on a virtual flow, there may be lot of missing scenarios.

In my opinion it is great to have the functional tests written before development. But also they need to be revisited when the story is development complete. This will give the analyst come up with more scenarios that cannot be visualized until testing the story. Developers need to have the functional tests in mind before they make UI or other changes and work with the analyst in making the tests pass. If functional tests are ignored while making changes/decisions, it’s merely possible to have functional tests before development.

Decisions

Imagine that you are a CEO of a company and you have to make a decision on selecting one of the following teams. Which team will select and why?(Please leave ur answer as a comment)


Team 1: Has a good manager and has below average developers.


Team 2: Has good developers and a below average manager.

Tasking Sessions

Estimating a story card accurately is always a difficult task. We can be close to reality but never accurate. We should look at our estimates as a variable.

In our project, we developers discuss with analysts about a storycard, and come up with some high level tasks to complete that story card. Looking at those tasks we estimate ideal days (or some other unit system) to complete the story card. To be honest, sometimes we have been awfully off our estimation. Some members in our team question why to waste our time doing tasking when we anyhow go wrong with our estimates whether we task out our stories or not. I totally accept to this argument, by tasking our story we will never get our estimates right. It could be closer to reality but not right("estimates right" sounds like an oxymoron). But (pardon my English) task of "tasking" is not just meant for estimating our story cards but it has many other benefits too. It helps,

1) To get better understanding about our story card
Tasking session allows (or forces) developers and analysts to look a little closer at the story cards. As analysts are right there, it is easy for developers to ask questions about some ambiguous parts in story cards.

2) To have a domain discussion
Tasking session makes developers and analysts to have domain discussion. Developers and analysts, when tasking can see if there is any domain model change for example adding a new domain object

3) To knowledge transfer to new developers.
By involving in tasking sessions, new developers will be able to understand more about why and what needs to be done for a story card.

4) To find some gaps in analysis
Tasking forces developers to have more understanding about a story card. So developers tend to ask more questions to Analysts. When answering to developers' questions, analysts will be able to find some scenarios he/she never thought about before or some gaps in story card.

5) To find whether a story is too big
Tasking gives us a better idea about the size of the story. So it will be easy for analysts and management team to decide whether to break the story into two or more manageable stories.

So I feel "tasking" is a beneficial activity in software development.

Pair Programing - Myth 1

Myth 1:

You don’t need a pair when you are doing a simple “if” condition.

Reality:

You need a pair to make sure, that you need that “if” condition.

Domain Discussion

Everybody knows the advantages of having domain discussions (if not please read Domain Driven Design by Eric Evans), but still it is one of the most under rated activity in software development. Most teams talk about test driven development, test coverage (this is an over rated activity), estimation, velocity...etc but only few among them talk about domain model. If we do not have a proper domain model, it will be very difficult for any project to be successful no matter what methodology we follow or what driven development we do. I was fortunate to work in a project where we had domain discussions. I was amazed by the change it brought to our project. I knew Domain Discussions have many advantages, but I never knew it will have this much impact in a project until I actually did it. Not only developers were involved in our domain discussions, even business analysts and quality analysts were actively involved. From domain discussions developers were able to better understand business. That way, it was easy for us to make our domain model close to business model. These are the few things I learnt from my project

1. Domain discussion is a MUST for any project

Just Do it!

2. Keep domain discussion casual and flexible.

We want a free flow of communication between team members in these discussions. By keeping it casual and flexible, it will be more like a discussion rather than a meeting.

3. Not only developers, even business and quality analysts should be involved.

This is very important. One of the goals of domain discussion is to create a common language between developers and analysts. If analysts are not involved, this purpose would not be solved and there will be no one to verify if the domain model is similar to the business model.

4. Have domain discussion at least every other week.

By discussing about the domain every other week, all model changes will be communicated within the team. The developers will be able to correct domain earlier from the feedbacks they get from the Analysts.

Testing Email Components

I always made sure I write tests before writing a method in an object.This gives me a clear idea what this method has to do.In my current project, I needed a method that sends a email. I was not sure how to write a test for this method. Then Pat Gremo ( another ThoughtWorker ) told me to check out the Dumbster (http://sourceforge.net/projects/dumbster) , a simple SMTP server that we could use in our automated Test suites.It was so simple to incorporate in my JUnits.
This is how I incorporated Dumbster in my Junit.

Method to Test:-
public void sendMessage(String hostName,
String portNo,
String addrFrom,
String nameFrom,
String addrTo,
String nameTo,
String subject,
String message) ;

JUnit:-
import java.util.Iterator;
import junit.framework.TestCase;
import com.dumbster.smtp.SimpleSmtpServer;
import com.dumbster.smtp.SmtpMessage;

public class EmailTest extends TestCase{

public void testSendMessage() {

EmailSender emailSender = new EmailSender();

//Starting the Dumbster's SMTP Default Server. It listens to port No 25
SimpleSmtpServer server = SimpleSmtpServer.start();

//Sending the message
email.sendMessage("localhost",
"25",
"siva@junit.com",
"tester",
"Siva@nowhere.com",
"Siva",
"Test Email",
"I am glad u got it");

//Stopping the SMTPDefault Server
server.stop();

//Checking no of emails received my the SMTPServer
assertTrue(server.getReceievedEmailSize() == 1);

//Getting all the emails recivied by SMTP Server as an Iterator
Iterator emailIter = server.getReceivedEmail();
SmtpMessage email = (SmtpMessage)emailIter.next();

//Checking the Subject of the email
assertTrue(email.getHeaderValue("Subject").equals("Test Email"));

//Checking the To Address of the email
assertTrue(email.getHeaderValue("To").equals("Siva "));

//Checking the From Address of the email
assertTrue(email.getHeaderValue("From" ).equals("tester "));

//Checking the Message of the email
assertTrue(email.getBody().equals("I am glad u got it"));

}

}

For information on Dumbster check out these sites,
http://sourceforge.net/projects/dumbster
http://www.javaworld.com/javaworld/jw-08-2003/jw-0829-smtp.html

When to do Interactive or State based testing?

Take this code snippet for example.

public void doSomethingAndSave(){
doSomething();
getDao().save();
}

For the above method, we might have these following behaviors to verify.

Behavior 1) shouldCallDaoSave
Behavior 2) shouldDoSomething

Behavior 1 is perfect for using interactive based testing. By using mock we could avoid going to database.

In behavior 2, we do not care whether it is calling getDao().save(), all we want to verify is whether it is doing “something" that we specify. In this situation state based testing is better than interactive based testing. By using dummy stubs, we do not have to change this behavior even if we decide not save anything after doing “something”. But if we used interactive based testing for this behavior, then we would have to fix this behavior (even though nothing has changed in behavior that it specifies) when we refactor this method not to save anything.

Mocks are evil!

Mocks are evil! Ok that is kind of rude; mocks are useful when we are doing interactive based testing. The question whether Interactive based testing is good think to do. Interactive based testing is to check whether a particular method is calling another object with some particular parameters x number of times. So many bad things are happening here.

1) We are testing the implementation rather than verifying behavior.

2) As our interactive based tests are tied to implementation, refactoring becomes a pain. Refactoring will take more time as we need to fix interactive based tests.

3) It puts us in wrong perspective. Instead of thinking in terms of behaviors in our unit (tests / contexts) we end up thinking about implementation like whether this method calls that method.

Domain Driven Design

Test Driven Design, Behavior Driven Design …etc does not make sense if we do not do Domain Driven Design.

Please read this book “Domain Driven Design”.