Do you always experience similar results with two different projects that are very similar? Or do you ever have two similar projects that have significantly different outcomes? I’ve had this experiences. One project had the most typical elements of a failure project: go-live was delayed; we had an over-run budget; there were endless bugs and exhausted team members. But the other one was the opposite: the release was on schedule, there were few bugs, and each team member enjoyed work-life balance .

What factors cause such difference? When we hold a retrospective meeting, we can get a long list of items that we do differently between the two projects. But which one will be on the top of the list? I didn’t have the answer for a long time until recently when I reviewed the release plan of the first project. I found the following statement at the Assumption section of the release plan:

Scope is locked. All Functionality must be delivered before XXX.

This is a quite popular statement in many projects’ SOW or release plan. It may not cause problems for the average project; but it has the potential to make a more complex project a nightmare.

We have team members who attended a Boot Camp where they learned skills such as how to write a unit test.  They are very smart and created a lot of unit tests for their code. We use unit test coverage rates to judge the quality of unit tests. The boot camp team got a 87.5% coverage rate, which is quite high.

But except for coverage rate, what is good unit test? I would like to quote the following items from the author of “The Art of Unit Testing”

• Able to be fully automated
• Has full control over all the pieces running (Use mocks or stubs to achieve this isolation when needed)
• Can be run in any order  if part of many other tests
• Runs in memory (no DB or File access, for example)
• Consistently returns the same result (You always run the same test, so no random numbers, for example. save those for integration or range tests)
• Runs fast
• Tests a single logical concept in the system
• Readable
• Maintainable
• Trustworthy (when you see its result, you don’t need to debug the code just to be sure)

From my view, unit test code is part of function code. Any code standards applied to function code also need to be applied to unit test code. And the most important is unit test codes need to be refactored constantly.