How to start unit-test old and new code?

问题:

I admit that I have almost none experience of unittesting. I did a try with DUnit a while ago but gave up because there was so many dependencies between classes in my application. It is a rather big (about 1.5 million source lines) Delphi application and we are a team that maintain it.

The testing for now is done by one person that use it before release and report bugs. I have also set up some GUI-tests in TestComplete 6, but it often fails because of changes in the application.

Bold for Delphi is used as persistance framework against the database. We all agree that unittesting is the way to go and we plan to write a new application in DotNet with ECO as persistance framework.

I just don't know where to start with unittesting... Any good books, URL, best practice etc ?

回答1:

Well, the challenge in unit testing is not the testing itself, but in writing testable code. If the code was written not thinking about testing, then you'll probably have a really hard time.

Anyway, if you can refactor, do refactor to make it testable. Don't mix object creation with logic whenever possible (I don't know delphi, but there might be some dependency injection framework to help in this).

This blog has lots of good insight about testing. Check this article for instance (my first suggestion was based on it).

As for a suggestion, try testing the leaf nodes of your code first, those classes that don't depend on others. They should be easier to test, as they don't require mocks.

回答2:

Writing unit tests for legacy code usually requires a lot of refactoring. Excellent book that covers this is Michael Feather's "Working Effectively with Legacy Code"

One additional suggestion: use a unit test coverage tool to indicate your progress in this work. I'm not sure about what the good coverage tools for Delphi code are though. I guess this would be a different question/topic.

Working Effectively with Legacy Code

回答3:

One of the more popular approaches is to write the unit-tests as you modify the code. All new codes gets unit tests, and for any code you modify you first write its test, verify it, modify it, re-verify it, and then write/fix any tests that you need due to your modifications.

One of the big advantages of having good unit test coverage is being able to verify that the changes you make don't inadvertently break something else. This approach allows you to do that, while focusing your efforts on your immediate needs.

The alternate approach I've employed is to develop my unit tests via Co-Ops :)

回答4:

When you work with legacy code, mock objetcs are really usefull to build unit tests.

Take a look at this question regarding Delphi and mocks: What is your favorite Delphi mocking library?

回答5:

For .Net unittesting read this : "The Art of Unit Testing: with Examples in .NET"

About best pratices :
What you said is right : Sometimes, it's difficult to write unit tests because of the dependancy between classes... So write unit tests just after or just before ;-) the implementation of the classes. Like this, if you have some difficulties to write the tests, maybe it means you have a design problem !