Agile FAQs
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed

Recent Thoughts
Tags
Recent Comments

Archive for September, 2005

Why I'm not a great fan of Agile Enablement Gigs

Thursday, September 29th, 2005

I think most of us(folks in ASCI) don‘t know enough Agile to go and consult a company in India on how to use agile. Agile is not just a set of simple practices. It‘s a lot more than that. Agile is a huge cultural paradigm shift. This cannot be done with a bunch of trainings sessions.

What really is Agile? Am I doing Agile? How much agile your process is? Am I doing 100% XP/Scrum?
Well these questions/statements don‘t really make any sense to me. So against what are we going to measure ourselves?
The obvious answer would be, if the team delivers to client‘s satisfaction, then we [the enablers] have done our job.
Project deliver to Client‘s satisfaction != Agile
Agile is just a small component in this whole project delivery maze.

To me it‘s more of politics management than agile enablement. Which is what happens in any consulting gig.

If you are interest in developing cutting edge software applications, agile enablement will not really satisfy your appetite. Most of the folks I know of who are doing agile today are people belonging to this category.

We [agile enthusiasts] are very skeptical of “The Process Folks”. People who come in and tell you how to develop software without having any/lack of hands on experience. We don‘t want to put ourselves in the same category.

Is Agile Enablement just another consulting gimmick?

Playing with EasyMock

Sunday, September 25th, 2005

I just started using EasyMock on my current project. So far, I have not used it much, but I think it would be helpful to some people to put some basic notes on my approach to using easymock.

I started playing around with JDBCFixture (A set of useful fixtures for Fitnesse). I was happy to see JDBCFixture using easymock for some of the JDBC stuff. I think this would be a good starting point for someone to understand easymock.

Lets consider a simple DeleteFixture. Following is the behavior that is expected on a DeleteFixture

1.Given a tableName, it should delete all the rows from the table

fitnesse.jdbc.DeleteFixture aTable

2.Given a tableName and where clause, it should execute the delete statement

fitnesse.jdbc.DeleteFixture aTable
where id=1

The core functionality of the DeleteFixture is basically to extract the correct data (tableName and the where clause) and form the corresponding SQL, which it can then execute on the database through the JDBC calls.

So we are interested to test the following sequence for the first scenario: (just TableName is given)
1.get a connection instance
2.connection.prepareStatement(“delete from tableName“) is called. We are not interested in how the sql is formed
3.preparedStatement .executeUpdate() is called
4.preparedStatement.close() is called
5.connection.close() is called

So what would a unit test for DeleteFixture look like?
Unfortunately with simple JUnit this kind of testing is not possible. So what do we do? You guessed it right, we use Mocks.

Using easyMock, the test class would like this:

package fitnesse.jdbc;

import fit.Fixture;
import fit.Parse;

import junit.framework.TestCase;

import org.easymock.MockControl;

import java.sql.Connection;
import java.sql.PreparedStatement;

public class DeleteFixtureTest extends TestCase {
private Connection connection;
private MockControl mockConnectionControl;
private MockControl mockStatementControl;
private PreparedStatement statement;

protected void setUp() throws Exception {
super.setUp();
JdbcConnectionFixture.driver = “org.gjt.mm.mysql.Driver“;

mockConnectionControl = MockControl.createControl(Connection.class);
connection = (Connection) mockConnectionControl.getMock();

mockStatementControl = MockControl.createControl(PreparedStatement.class);
statement = (PreparedStatement) mockStatementControl.getMock();
}

protected void tearDown() throws Exception {
mockConnectionControl = null;
mockStatementControl = null;
connection = null;
statement = null;
super.tearDown();
}

public void testJdbcCallSequenceForJustTableName() throws Exception {
JdbcConnectionFixture.setConnection(connection);

connection.prepareStatement(“delete from tableName“);
mockConnectionControl.setReturnValue(statement);

statement.executeUpdate();
mockStatementControl.setReturnValue(1);

statement.close();
connection.close();

replay();

Parse table = new Parse(”
fitnesse.jdbc.DeleteFixture tableName

“);
Fixture fixture = new Fixture();
fixture.doTables(table);

verify();
}

private void replay() {
mockConnectionControl.replay();
mockStatementControl.replay();
}

private void verify() {
mockConnectionControl.verify();
mockStatementControl.verify();
}

}

Let‘s start from the setUp() method:

MockControl mockConnectionControl = MockControl.createControl(Connection.class);
Connection connection = (Connection) mockConnectionControl.getMock();

MockControl.createControl() takes a parameter of type Class. We can pass Class, Abstract Class or even Interfaces. This would return the MockControl object.

mockConnectionControl.getMock() returns the actual mock object.

Now let‘s look at our actual test method

public void testJdbcCallSequenceForJustTableName() throws Exception {
JdbcConnectionFixture.setConnection(connection);

connection.prepareStatement(“delete from tableName“);
mockConnectionControl.setReturnValue(statement);

statement.executeUpdate();
mockStatementControl.setReturnValue(1);

statement.close();
connection.close();

replay();

Parse table = new Parse(”
fitnesse.jdbc.DeleteFixture tableName

“);
Fixture fixture = new Fixture();
fixture.doTables(table);

verify();
}

In the first statement JdbcConnectionFixture.setConnection(connection); we are injecting our mock connection into the system.

In the following calls we are setting the expections:

connection.prepareStatement(“delete from tableName“);
mockConnectionControl.setReturnValue(statement);

statement.executeUpdate();
mockStatementControl.setReturnValue(1);

statement.close();
connection.close();

Please note that this is the sequence of JDBC calls we expect. One can this of this as if we are recording a macro.

The replay() call tells the system that we have finished recording, following will be the actual execution. Hence after the replay() we call the actual method call that we want to test.

Parse table = new Parse(”
fitnesse.jdbc.DeleteFixture tableName

”);
Fixture fixture = new Fixture();
fixture.doTables(table);

Finally we call the verify() method, which checks if the macro recording sequence was same as the actual method call sequence with the expected paramter values.

Testing with Mocks using EasyMock can be as simple as this.

Agile Software Community of India (ASCI)

Tuesday, September 20th, 2005

Agile Software Community of India (ASCI) is a registered society founded by a group of agile enthusiasts and practitioners from companies that practice Agile Software Development Methodologies.

ASCI was formed to create a platform for people from different software organizations to come together and share their experience with Software development methodologies. The focus was on Agile and related light weight methodologies/philosophies. ASCI evangelizes itself to be a facilitating body which fosters lightweight methodologies in software development in India. ASCI is working with Universities and Student chapters to increase Agile awareness within the academic circles.

ASCI is planning to organize introductory conferences in different IT cities in India. So far ASCI have successfully organized four conferences on Agile in India. These conferences are initiatives to reach out to other practitioners and to increase the awareness of Agile Methodologies in India. These conferences helped us generate a lot of interest among the local software community, academics and students. There are queries from companies on how they can adopt agile. The academicians are interested to have student chapters and agile workshops organized on regular basis in their Universities.

While more and more organizations in India are going Agile, ASCI would like to build a user community of Agile practitioners in different parts of India. Conferences are a nice way of bringing this user community together. ASCI intends to have periodic meetings and workshops for practitioners to share their experiences from the field and improve their practices.

ASCI welcomes individuals and corporate to become ASCI members and help us with the Agile movement.

For more details: http://agileindia.org/
Mailing list: http://groups.yahoo.com/group/agileindia

A night in Chicago

Saturday, September 17th, 2005

A few weeks back I went partying with a bunch of ThoughtWorkers from the Chicago office. First we went to club called Sonetheque. Guess what? We had arrived even before the club had opened. To kill time, we headed to a near by Veg restaurant. After a few drinks and some crazy appetizers, we landed at Sonetheque again. To our surprise they did not let me in coz I was not carrying my identity on me. So we had to head back to the hotel to pick up my passport. Remember, if you are going out clubbing in the US, it‘s always better to carry your identity [passport/US driving license].

We soon forgot all this pain and found ourselves swinging to the awesome music. That night was a special Berlin minimal techno or minimal house dubtec music night. The DJ rocked. The party stopped at 2:30 in the morning and we guys headed out for some food.

This is was the best part so far. We guys went to a place called Wiener Circle. This place is very famous for its hotdogs. When we entered this place, there was all kinds of screaming and abusing going on. I thought, there was some dispute between some customers and the restaurant staff. In the next few minutes, I realized that was the culture of this restaurant. And all this screaming and shouting is what really makes this place special.

So if you want to order a hotdog, this is how it works:
Customer: “Hey you f**king bi*ch, give me a hotdog right now or I will chop off your head“
Staff: “What kind of a hotdog you want, son of a bi*ch”
And this screaming would continue for a while till they get the hotdog and they pay…

It was amazing to watch the energy levels in this place. At 3:00 in the morning, people were really screaming and enjoying. This place reminds of the Fish book. It‘s all about how to make your work interesting and satisfy your customers.

Organizations like this creates a place in the customers mind without trying too hard. They are different and they rock.

Types of Tests on Agile Projects

Sunday, September 11th, 2005

I usually categorize my tests in these 4 types:
1. Unit isolation tests – Test each unit in isolation. Written by Devs.
2. Unit integration tests – Test units in context. Written by Devs.
3. Integration tests – Test across the layers. Written by Devs and Testers.
4. Acceptance / Functional tests – Tests across the layers, but more focused on end user driving it. Written by Customers/Business Analyst and Testers, with the help of Devs. These are used for regression testing as well.

Pragmatic Unit Testing

Saturday, September 10th, 2005

Recently I was introduced to the Pragmatic Unit Testing book. This seems to be a nice summary of what we have been following as guiding light for unit testing on various projects.

One thing to note here is, in the Agile world, Unit tests are not a testing mechanism.

Reasons why I write unit tests:
1.They are the best, up_to_date functional spec.
2.They are the best, up_to_date design spec. If I want to know how this class behaves or how this class interacts with other classes, I would look at its unit test
3.They form a test harness around my code. Makes me feel so much secure about my code. I‘m no more in this illusionary world that my code works.

While I still have to figure out a best answer for what to test and what not to test, there is a good summary of unit testing principles that can help.

http://www.pragmaticprogrammer.com/starter_kit/utj/StandaloneSummary.pdf

    Licensed under
Creative Commons License