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”.