How to choose the hot area to add UT for legacy code?

[xiaohong liu]

Hi, All

When we try to add UT to legacy code, sometimes the first problem we
have to face is not the techinology how to get production code
testable, but how to identify the hot area and how to plan the test
cases.
So my question is how to identify the hot area? I think the past bugs
fixed are kind of hint. But any else rules we can follow? Should the
UT focuse on some flow very complex?

thanks
Xiaohong Liu

[Bas Vodde]

Hi,

Most companies I've worked with don't just focus on adding unit test to existing code, but they also will need to add new functionality to the product.

Therefore, usually I recommend to add the unit tests to the parts of the code where the new functionality is going to be added. That cleans that part up and makes it easier and safer to add new features.

In the end, the purpose of unit testing is *not* testing...

Bas

[Terry Yin]

I wrote a python script called 'hotspot.py' to help identify the hot spots in the code. This is done by the svn blame command, to find the most frequently modified parts of a repository. In some ideal assumption, adding UT to these parts will get the highest ROI. I can share it, if anybody need it:-)

------

In my personal opinion, merely adding UT to legacy code just doesn't pay back. From psychological point of view, the purpose of adding UT is to give you the confidence of your code. But adding UT to legacy code will only make you upset. Because, adding UT to legacy code means you have to change your legacy code dramatically.

So, like Bas said, it's better to do it alone with your new development or bug fixing, where you have to modify the legacy code any way.

If you really want to add UT for legacy code, why not try re-writing it:-)

-terry

--

-terry

-------------------------
Blog: http://terryyin.blogbus.com/
twitter: http://twitter.com/terryyin

[James Grenning]

Like you've heard from Bas and Terry, add tests where you are going to change the code. That's where the new risk is.

James

[xiaohong liu]

Thanks all.
Can I understand like that?
1. Don't add UT to leagacy code JUST because you want to add UT. No
code change, no UT.
2. If you have some code change, such as refactor existing code, or
new feature, or bug fix, we can select some relative leagacy code to
add UT to make sure the functions still work after code change.

thanks
Xiaohong

[Bas Vodde]

Hola,

> Thanks all.
> Can I understand like that?
> 1. Don't add UT to leagacy code JUST because you want to add UT. No
> code change, no UT.

Yah, and another exception is when you are doing it mainly for learning perspective. This sometimes happens in a coaching environment

> 2. If you have some code change, such as refactor existing code, or
> new feature, or bug fix, we can select some relative leagacy code to
> add UT to make sure the functions still work after code change.

Yup.

Bas

[xiaohong liu]

But how about such scenario? In the leagacy code, there are some embranchments where normal function test on target system can't cover, Or we need to boundary test through UT, since some value can't be generated when SW normally run on target system?

thanks
xiaohong

2011/8/29 Bas Vodde <ba...@odd-e.com>

[Bas Vodde]

Hi,

Sure... but ... it is existing code and has already been used and tested, or?

Bas

[xiaohong liu]

Yes. It is existing code and has been tested to make sure the work flow is correct. 

2011/8/29 Bas Vodde <ba...@odd-e.com>

[Bas Vodde]

Hiya,

Well, if you find it useful, you can do it still :)

As I think I mentioned earlier, usually unit testing is not really for finding defects, but for preventing them :) But, if you find bugs in this way, go ahead :)

Bas

[James Grenning]

I wanted to add this advice about proactively adding tests to existing code, but the publisher was too restrictive.  So 

"Bret Pettichord, Cem Kaner, James Bach. Lessons Learned in Software Testing: A Context-Driven Approach. John Wiley & Sons, New York, 2002."  was not quoted in my book.  But I still like their advice.  We've already hit the first item on their list:

• Test things that are changed before things that are the same. Fixes and updates mean fresh risk.
• Test core functions before contributing functions. test the critical and the popular things that the product does. Test the functions that make the product what it is.
• Test capability before reliability. Test whether each function can work at all before going deep into the examination of how any one function performs under many different conditions.
• Test common situations before esoteric situations. Use popular data and scenarios of use.
• Test common threats before exotic threats. Test with the most likely stress and error situations.
• Test for high-impact problems before low-impact problems. Test the parts of the product that would do a lot of damage in case of failure.
• Test the most wanted areas before areas not requested. Test any areas for any problems that are of special interest to someone else on the team.

James

--------------------------------------------------------------------------------------------

James Grenning Author of TDD for Embedded C

www.renaissancesoftware.net http://pragprog.com/titles/jgade/

www.renaissancesoftware.net/blog

www.twitter.com/jwgrenning

[Terry Yin]

Hi,

Sorry for the late response:-) I haven't had access to my old computer for a while.

And I'm sorry that this script doesn't have any UT, I do usually have UT for my scripts, but not this one.

terry

On Sun, Aug 28, 2011 at 9:51 AM, xiaohong liu <xiaohongs...@gmail.com> wrote:

Hi, Terry

Thank you so much for your advice. I'm very interested in your script.
It'll be wonderful if you can share it:)

thanks
Xiaohong Liu