• Some questions and answers of unit test (http://blog.esofthead.com/?p=51)
• Enhance the unit test using Annotation approach (http://blog.esofthead.com/?p=67)
• Unitils - enhance unit test using Annotation approach (http://blog.esofthead.com/?p=77) - Unit test spring bean and database testing with unitils library.
• Unit test with Spring Dynamic Modules (http://blog.esofthead.com/?p=106) - Unit & Integration test for Spring DM.
• Integration Jackrabbit OCM and Spring (http://blog.esofthead.com/?p=174) - Unit test against content repository.

Introduction
There are some techniques to write testing application services interact with database. There are:

Using Mock Object

Mock object are simulated objects that mimic the behavior of real objects in controlled ways. Using the mock object could be increase the performance of unit test, reduce the cost of maintenance also reduce the complexity of setting the test objects. In java world, easymock (http://easymock.org/) is the good mock library to help developers write mock easily.

Using Development Database

Testing runs against the development database. It has separated testing database per each workspace. It takes more time in setting testing environment, more time to execution, but it is useful in case we need to write the testing for database test script (not focus on business on service layer).
Database testing with DbUnit

DbUnit (http://www.dbunit.org/) is a JUnit extension targeted at database-driven projects that, among other things, puts your database into a known state between test runs. You should use dbUnit to write unit/integration testing on service layer. However, dbUnit could not be use in:

• Performance testing: development performance could say nothing about the performance of database.
• Stress/Volume testing: you could not write millions of database records using xml format.

With the completed database schema which has many foreign keys, it may takes you much time to maintain the known state of database, so one practice is omitting all foreign keys in testing database. It will reduce much time of maintaining database test script.

Integrate DbUnit and Spring Testing

Spring provides the excellent testing framework since 2.5 supports java annotation (http://static.springframework.org/spring/docs/2.5.x/reference/testing.html). To configure the Test Context, Spring use the test runner is SpringJUnit4ClassRunner. So in order to integrate DbUnit with Spring Testing framework, we extended this runner by our own class EngroupClassRunner and our testing has format:

@RunWith(EngroupClassRunner.class)
@ContextConfiguration(locations = { "/spring-service-test.xml" })
public class ExtendedTest{
    ...
    @DataSet
    @Test
    public void testSave() {
        ...
    }
}

With EngroupClassRunner, it would use the database script locates in the same location in testing class (for example: the database script would be located at com/engroup/module/hr/service/EducationTest.xml if the test class has the full name com.engroup.module.hr.service.EducationTest).

Override the database source to database testing configuration

Replace the spring configuration file by another spring configuration file in testing. For example: replace the code

<osgi:reference id="dataSource" interface="javax.sql.DataSource" />
<bean id="hrSqlMapClient"
    class="org.springframework.orm.ibatis.SqlMapClientFactoryBean">
    <property name="configLocation"
        value="classpath:hr-sqlmap-config.xml" />
    <property name="dataSource" ref="dataSource" />
</bean>

By

<bean id="dataSource"
  class="com.engroup.test.DataSourceFactoryBean" />

<bean id="commonSqlMapClient"
        class="org.springframework.orm.ibatis.SqlMapClientFactoryBean">
    <property name="configLocation"
        value="classpath:common-sqlmap-config.xml" />
    <property name="dataSource" ref="dataSource" />
</bean>

with com.engroup.test.DataSourceFactoryBean is the factory bean creates the data source from testing configuration and points to testing database.

and you write the database script in xml format as usual dbUnit format:

<!DOCTYPE dataset SYSTEM "../../../../../../engroup.dtd" >
<dataset>
    <m_hr_education id="1" course="Java" durationinmonth="10" institute="USA"/>
    <m_hr_education id="2" course="C#" durationinmonth="5" institute="VN"/>
</dataset>

Finally, you run the test to see whether your service is ok.

I include the some core classes of Engroup testing, not the whole package could be testable (because if I do so, you must have the testing database at your side). Here is the attachment.

• Engroup is the mix project of Java and Flash/Flex with server side is written by Java and front-end is developed by Flex.
• Now, there are many projects:
• • Engroup server has 29 sub-projects (include test projects for Engroup modules and documentation project). The number of projects would be increased in future. Maven is the main tool to build Engroup server projects. In some cases, we combine with Ant via maven-ant tasks to utilize Ant power to support doing tasks that Maven can't.
  • Engroup client has 18 sub-projects. Ant is the main tool to build Engroup client projects by mainly using Flex-Ant task also our custom tasks to generate the code from Engroup server.
• Developers commit code daily.
• Long list of project dependencies: Engroup module projects depend on Engroup core and common modules.
• Back-end services must have unit test for its implementation.
• Database backup must be generated in every build and Engroup installer must be available in every successfully build.

Related build tools:

• Hudson (https://hudson.dev.java.net/): one of the best CI Java build server. Simple to run, simple to use. Have many plug-ins and a clean dashboard to follow the build status.
• Nexus (http://nexus.sonatype.org/): a powerful and robust Maven manager. Nexus is very easy to use and we deploy our Engroup server modules to our nexus server.
• Maven (http://maven.apache.org): an excellent build tool. A must tool for any Java projects.
• Ant (http://ant.apache.org): another excellent Java build tool. A must tool for any Java projects. A combination of Ant and Maven strengthen the power of each tool.

Our standard build process:

1. CI server (Hudson) will get the latest sources from SVN server.
2. Build Engroup projects order depends on project dependencies.
3. Run unit test.
4. Make the reports (thanks for the help of Maven): checkstyle, pmd, junit, cobertura.
5. Deploy Engroup modules to maven repository manager if the build is success.
6. Back up database if all module builds are success.
7. Make the Engroup installer.

Manage projects and build process by CI server (Hudson)

It is fairly easy to create the new build job on Hudson, create 'Create Job' link at Hudson CI server and simply fill necessary information

You can integrate Unit test, checkstyle, cobertura, pmd to project dashboard by selecting them in build settings section.

And you could manage builds and its status on dashboard page, for multiple projects it is better if you customize the list view of modules. For example, in our project we make the customization view for client and server view also view of common artifacts (documentations, installer).

Monitor project health
We can manage the health of project via the following factors:

• Build status: how many failure or success of builds.
• Build warnings: compiler warnings, code warnings (checkstyle, violations) or defined threshold of checking tools (unit test coverage, findbugs)
• Other information: code metrics, duplicate code, source code.
• Project information: development information, license, source repository etc

Go to the Maven site to see project information:

and we can visit some sections to see the detail:

The values of applying CI in our project:

Applying continuous integration in our project give us many advantages:

• The whole process is automated (even backup database task) - no manual task in our build process. No any human mistake causes the build broken, no build check-list is needed any longer.
• Feedback to development status as soon as possible via unit test result and code warnings and some useful metrics.
• Give the project status as you need.
• Managing multiple projects status in one place.
• Developer could get the latest other works as soon as possible (thanks for nexus - open source maven repository).

Applying CI in your project should be the good option for your project as we get in our projects. Just takes some hours to make all things are run properly but the benefits you have is far greater than the effort you spent. Let's try, see and enjoy!

Instead of writing tasks report at the end of week (this way place project member in passive way, they only record what they are assigned to do by PM), each project member spend 15 minutes/day (75 minutes/week) to answer three questions "What have you done? What do you plan to do? What impediments do you have?". The Scrum Master only set the goals to be completed in week and project members are freely to plan their tasks to complete their goals. This cause project member active to think what they do, and they manage their tasks in order complete project's goals not wait the instruction from PM. Before applying Scrum practice, we receive many complaints like "Members are not active in their jobs! They do not raise problems to us etc", after applying the Scrum daily meeting we can update the project status every day! And people active to solve problems. If you have not applied daily standup meeting before, you should try it soon!

There are some tips to make the daily standup meeting more effectively:

· Do not try to solve problems! Only related people seek the solutions later not in daily standup meeting.

· Limit the number of members less than 7 members and they only focus into 3 main questions, no more and no less.

· Scrum master deliver the project information briefly (news, project change etc). Any message not belong the daily meeting scope should leave for weekly meeting or another group meeting.

· Daily meeting should proceed at the beginning of day, not middle or very late. Do not let the short meeting impact to current employee's works

· Project members should report descriptively about their task. No use ambiguous statements like 'Yesterday, I fix some defects or do some bugs'. Report task of one day do not take a lot of time of developer. With long time tasks, it should be divided into smaller tasks (1-3 days) and have output to make all developers can understand the work done by reporters

In the project has both lazy developers and non-lazy developers, project managers usually do the wrong thing that assigns the lazy developers more jobs to share workload with the non-lazy ones, that causes all people tend to become the non-lazy ones. In this case, project manager should motivate people become to the lazy developers, it is an art!

- The different speed of working among associates. The clever can interfere much the thinking of other and developers are not peer but teacher and student relationship. With teacher-student relationship, it takes time for senior to work the same workspace with less mature one and we have other types of training instead of pair programming.

- Pair programming should not applied in 'political' or unfriendly environment. People tends to protect themselves and try not show their weakness to others.

- Some people just like to work lonely. They do not like any involve during they code until their works are finished.

- We do not need two guys do for simple works.

- Sometimes people need relax, other member will force them work while they are tire. There are some guys can work without relax within 4 hours but others need, the different focus level in work can cause people tire and protect against pair programming.

With above reasons, I do not see pair programming can be applied to many teams especially the big team because they are many tyles of working, any fail in one pair can impact to others. However, without any close cooperation among developers than current, it also cause issue about quality and knowledge management, the result is clear: code is not reviewed well (code review session is not effective because people only select random source file for code review in meeting), people can not share knowledge of coding and works etc. The simple thing we can improve our works to full code review to all source codes, two people understand the same code base is performing the peer review regularly. Instead dividing into pairs for coding, we let pairs do review only, one will code and other will review their works at the end of day. Pair review should be performed every day because when some pair leave works not reviewed daily basics, they tend to select random files for review only when managers request and the effectiveness is not much. Review other works in daily basic will take much time at the beginning, but it takes more speed in future when people is aware with other's source code, business domain. We also sure each line of source code are 'done' by pair (one code and one do inspection), if there is any conflicts in pair, the technical lead will join to solve the issue. One drawback of pair review with pair programming is the response time for fixing defects, pair programming do faster but I believe the benefits of pair review is worth for pair and it overcomes the limitations of pair programming to make it can be applied more wider area.

Scenario: I would like to test login function of some application use Ldap server as user information database. The unit test will launch the embedded LdapServer in each test method as the excellent guideline describe here http://directory.apache.org/apacheds/1.5/using-apacheds-for-unit-tests.html. Typically, I would like each test class launch embedded ldap server use the annotation EmbeddingServer:

@RunWith
(UnitilsJUnit4TestClassRunner.class)
@EmbeddingLdapServer
public classRoleLdapServiceTest {
@Test
public voidtestFindRole() {
Assert.assertNotNull(roleLdapService.findRoleName("ROLE_ADMINISTRATOR"));
Assert.assertNull(roleLdapService.findRoleName ("ROLE_TEST"));
...
}
...
}

To add the new module to Unitils is very simple:

1. Add the new module name in unitils.properties (you can see how to use unitils.properties to configure modules at http://unitils.sourceforge.net/tutorial.html#Unitils%20Modules):
   unitils.modules=database,dbunit,hibernate,easymock,inject,spring, ldap (Note that database, dbunit, hibernate, easymock,inject and spring are the built-in modules of Unitils, and I add ldap module for my ldap unit testing).
2. Add the related information for initializing our module in the same unitils.properties file
   unitils.module.ldap.className=org.nextss.util.test.ldap.LdapModule
   unitils.module.ldap.enabled=true
   ldap.username=uid=admin,ou=system
   ldap.password=secret
   ldap.authentication.method=simple
   ldap.factory.classname=org.apache.directory.server.jndi.ServerContextFactory
3. Create the annotation class that new module supports

   @Target(ElementType.TYPE)
   @Retention(RetentionPolicy.RUNTIME)
   public @interfaceEmbeddingLdapServer {
   }

   EmbeddingLdapServer is annotated to class and it is retained in runtime as we define in requirement

4. Create Module class corresponds the new module. This class must inherit the interface org.unitils.core.Module and override two methods void init(Properties configuration) and TestListener createTestListener(). The usage of these two classes are:
   - init is used to load any pre-defined configuration of defined module (in unitils.properties file)
   - createTestListener creates the TestListener for test events with the following orders:

5. • [Unitils] beforeAll
   • [Unitils] beforeTestClass - TestClass1
   • [Test] testBeforeClass - TestClass1 (not for JUnit3)
   • [Unitils] beforeTestSetUp - TestClass1
   • [Test] testSetUp - TestClass1
   • [Unitils] beforeTestMethod - TestClass1 - test1
   • [Test] testMethod - TestClass1 - test1
   • [Unitils] afterTestMethod - TestClass1 - test1
   • [Test] testTearDown - TestClass1
   • [Unitils] afterTestTearDown - TestClass1
   • [Unitils] beforeTestSetUp - TestClass1
   • [Test] testSetUp - TestClass1
   • [Unitils] beforeTestMethod - TestClass1 - test2
   • [Test] testMethod - TestClass1 - test2
   • [Unitils] afterTestMethod - TestClass1 - test2
   • [Test] testTearDown - TestClass1
   • [Unitils] afterTestTearDown - TestClass1
   • [Test] testAfterClass - TestClass1 (not for JUnit3)
   • [Unitils] afterTestClass - TestClass1
   • [Unitils] afterAll

In our case, we write the new module names LdapListener. Because, we want unitils read the annotation EmbeddingLdapServer at the beginning of running test class, we will override the method beforeTestClass:

@Override
public void beforeTestClass(Class<?> testClass) {
EmbeddingLdapServerclassAnnotation = getClassLevelAnnotation(EmbeddingLdapServer.class, testClass);
if(classAnnotation != null) {
log.debug("before test class");
serverOnline= false;
doDelete= true;
configuration= newLdapServerConfigDecorator();
port= -1;
}
super.beforeTestClass(testClass);
}

Next, we setup the partition'nextss' for ldapServer in method beforeTestSetUp after ldap server is started:
@Override
public void beforeTestSetUp(Object testObject) {
EmbeddingLdapServerclassAnnotation = getClassLevelAnnotation(EmbeddingLdapServer.class, testObject.getClass());
if(classAnnotation != null) {
// Add partition 'nextss'
MutablePartitionConfiguration pcfg = newMutablePartitionConfiguration();
pcfg.setId("nextss");
try{
pcfg.setSuffix("dc=nextss");
} catch(NamingException e) {
throw new RuntimeException(e);
}
....
}

After creating the partition, we import the data by using ldif file:
@Override
public void beforeTestMethod(Object testObject, Method testMethod) {
Class<?> testClass = testObject.getClass();
EmbeddingLdapServerclassAnnotation = getClassLevelAnnotation(EmbeddingLdapServer.class, testClass);
if(classAnnotation != null) {
try{
setUp();
} catch(Exception e) {
throw new RuntimeException(e);
}
InputStream ldifStream = testClass.getResourceAsStream(testClass.getSimpleName()+ ".ldif");
if(ldifStream == null) {
throw new NextssException("File: "+ testClass.getSimpleName() + ".ldif is not found");
}
try{
importLdif(ldifStream);
} catch(NamingException e) {
throw new NextssException(e);
}
}
super.beforeTestMethod(testObject, testMethod);
}

And the last, not miss to clean up data after each test method :
@Override
public void afterTestMethod(Object testObject, Method testMethod,Throwable testThrowable) {
EmbeddingLdapServerclassAnnotation = getClassLevelAnnotation(EmbeddingLdapServer.class, testObject.getClass());
if(classAnnotation != null) {
try{
tearDown();
} catch(Exception e) {
throw new RuntimeException();
}
}
super.afterTestMethod(testObject, testMethod, testThrowable);
}

It is very simple, right? . You can start writing test with Embedded Ldap Server will run and import data before each test method.
UserLdapServiceTest.javaLdapModule.javaLdapServerConfigDecorator.javaEmbeddingLdapServer.java

• DRY principle (Don't repeat yourself)
• Re-use test set up across test cases: put non-trivial test data in test set up method
• Clean test code as productive code

2. Evident data

3. All non-trivial methods must be passed unit test with 100% coverage ratio.

4. Unit test independent with:

• Other unit tests, order of unit test running
• Environment (operating system, hardware configuration, database …)

5. Fix broken test as soon as possible (it should be immediately)

6. After fixing defect, write unit test to prevent it re-occurs

7. All test cases must be passed at the end of working day

8. Test project code, not library code

9. Minimal maintenance of test code

10. If you can not write unit test for some functionality that means your code has problem! Refactor it immediately

Why it is a problem when we have common process for all projects in company? The reason is simple: each project has specific characteristics, and they require you must custom our process that adjust its context. However, three problems are raised:

• If company find that the current process can not cover some mistakes in some projects, they will add more rules to process (that means add more works to project members) to prevent this problem in other projects. We can understand this fact as they made the process more 'perfect'. However, such additional rules may not help other projects to fix its problem and project team members do not care its rules but it takes effort of considering, in some cases it takes time for them to do just because the rules define. The consequence of adding more rules is obvious, project effort is increased and company process becomes bigger and bigger. Some projects use a small part of this process, others use another part.
• It takes more time to maintain and study: the more bigger of process, the more time to learn . In addition, it also takes process engineer takes more effort of maintain the consistent of process. Any changes in process take a lot of effort to correct other places.
• Project team members apply process incorrectly: of course, all rules of one process can not apply all to projects. Company allows project can customize process that meet the project goals. However, if project has the right to customize company is not sure that what they think rules are un-needed is correct? Some cases, they remove some rules is the key factors to project success or when they choose another approach but no support from company. I give you a detail example: if there are two projects, one has 40 and other has 10 associates. The first project, client expect you have the formal communication with formal requirements and follow the requirement workflow strictly. The second one, client also require how you develop the application as soon as possible with high quality. With the first project, we can choose to apply the Business Modelling and use cases is the main artifact of managing requirements, it is supposed the company support this approach via templates, guidelines etc. But the second one, project should choose more agile approach of managing requirements such as writing user stories. If the company does not support, team must do by themselves. Of course, user stories may not added to process because in some meanings, user stories and use cases serve for the same purpose.

In manafactoring company, it is clear that we can have one workflow that serve for one product line. Software should not be considered as one product line but it should be divided into many groups that have the similar characteristic. That help company can control the software development process apply for each project strictly, project receive more guidelines for company and the effort to maintain will reduce. Just link to programming language: having a big process for all project is similar with you writing the program using procedure language, if we have one process for each kind of projects it is similar you use OO for programming. Of course, software development process also have inheritance characteristic . Here is the example:

Core Software Process: (the must for all projects in company)

- Requirements, Analysis and Design, Implementation (Code review check list), Testing (Unit test ...)

RUP Software Process: Core Software Process (custom for specific kinds of projects)

- Requirements (Business Modelling, Use cases, ...), Analysis and Design (template document...), ...

Scrum Software Process: Core Software Process (custom for specific kinds of projects)

- Requirements (User stories ...), Analysis and Design (template document...), ...stand-up meeting ...

The kind of project does not mean about the team size but we can categorize the project base on client's expectation (does they need the formal requirements, test cases ..., high quality product), project's context (lack of client support, domain knowledge is complicated, maintenance on legacy application) etc

Technorati : Project Management Software Development Process