Chinaunix首页 | 论坛 | 博客
  • 博客访问: 5174037
  • 博文数量: 1696
  • 博客积分: 10870
  • 博客等级: 上将
  • 技术积分: 18357
  • 用 户 组: 普通用户
  • 注册时间: 2007-03-30 15:16
文章分类
文章存档

2017年(1)

2016年(1)

2015年(1)

2013年(1)

2012年(43)

2011年(17)

2010年(828)

2009年(568)

2008年(185)

2007年(51)

分类: 项目管理

2012-01-05 15:29:31

Let me illustrate the importance of unit testing with a budget / motivation nightmare we lived in one of my job.

The Monster

We had an in-house system in our application to test whether or not a user can access a feature / button / function.

A button in the GUI could be activated or do different actions depending on the user’s permissions.

To be even more precise: depending on the context and the state of the object you worked with, a button could be disabled or enabled. And even drag and drop behavior could vary.

After 3 major versions of this software, with no unit-testing or even integration testing of this user control we discovered some bugs (of course).

Exploring them we discovered much more bugs. Besides: the code itself was not centralized and user control was done differently in each part of the code.

The Run In A Long Corridor With No End

There were no unit tests. So when I refactored to centralize the user access control I could not be sure of what I was doing (see episode 8).

Then we had no unit tests to see if a button was enabled or not.  What could we do? Manually test every combination. There were 336 or more.

It took us 2 people during 2 days. Talk about waste and costs!

Make It Fun

To make it more fun to test we shared a Free Google Spreadsheet (because our Paid Clearcase system could not support collaborative work of course).

In this sheet we placed all combinations and we put results of our tests in it, turning automatically to green or red the little boxes. At least it made us to complete the work fast.

Immediately afterwards, when the pressure went down I coded 36 unit tests to control a lot of possibilities.  It took me one hour. And now it saves us from another nightmare of this kind.

It runs every two minutes on our integration server (see next episode about this beast)

A Few Lessons To Draw:

·         Don’t let your team’s motivation go down when doing regression tests.  Make it fun and fast at least. It can cost you more than money.

·         Always, always, always encourage unit testing over regression testing. By the way, regression is a good term to describe the state of mine of an engineer doing manual testing.

·         Just let them implement tests during the coding. It’s fun all those green lights turning green one after the other when coding. It’s like a visible goal to software quality.

TODO

·         Ask one of your teammates if you have a situation like we had, a feature that has a lot of combinations.

·         Then immediately ask them to implement unit tests. It could save your day (or two). If they see you support unit testing over manual testing, they’ll thank you and you’ll keep them motivated.

For the developers out there

Did you ever run into this kind of situation? How did you react? Did your manager motivated you to build unit tests instead of organization test campaigns?

阅读(847) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~