Deployment workflow

A blog post – Staging Servers, Source Control & Deploy Workflows, And Other Stuff Nobody Teaches You ( Link), has correctly pointed out that only few companies and teams have tried to improve in this area. A well defined procedures, using automated tools for managing work flow, will really pay off. It will make the process of software development more visible and accountable. As the author pointed out, it will help to find the problem earlier before going to production. And by using better tools it is easier to roll back the whole system to previous working state.

Dependency in JUnit Test Cases

We had a debate in our team for identifying what are the best practices for writing JUnit Test cases for DAO classes.
Let’s consider an object Foo whose DAO is something like this:

Interface FooDAO{
getById(id);
delete(foo);
save(foo);
}

A corresponding test case for this FooDAO will be:


FooDAOTestCase{
setup(){
//Save Foo object to use in test
Foo fooToTest = new Foo();
//Either use save()
fooDAO.save(fooToTest)
//or use low level api
connection.executeQuery(“INSERT INTO FOO_TABLE values(1,’bar’);
}
testGetById(){
}
testDelete(){
}
testSave(){
}
}


Now in order to write test cases for testGetById and testDelete I have to make sure that there exists a Foo in DB. I can either use the save() or write a low level API like using jdbcTemlpate if I am using Spring to save it.
My colleagues were arguing that we should be using the already existing save() in the Setup() because of the following reasons:-

1. It already exists, don’t need to write code avoiding overhead
2. If the schema changes there will be only one place to change the SQL Query
3. If testGetById fails because save() failed we will find out where to go and fix it!

But, I insist on writing code separately to insert Foo instead of using save() for the following reasons:

1. The big reason is to avoid dependency to other code or method. That means if I am testing getById(), the scope of this test should be only this method. This is one of the best practices of using JUnit.
2. If I am doing Test Driven Development (TDD), I can copy those SQL statements into the production code.

I guess I will continue writing separate code in the future and advocating it in the future 🙂