views:

356

answers:

6

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 ?

+3  A: 

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 :)

Chris Arguin
Yes this is the holy grail, to make bigger changes without fear to break anything when it looks ok.
Roland Bengtsson
+6  A: 

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

Bruno Rothgiesser
Feathers' book is on my bookshelf, within arm's reach. One warning about it: Feathers is very strict about what he considers a decent unit tests and that may scare away unit-test beginners. Don't let that scare you! Other than that, a great book!
azheglov
I agree this is an excellent book, it's a bit of a dry read however. I've been inserting tests into an application I've been working on, at the moment each test covers a large chunk of code, but as I have to modify the code, I've been refactoring it to make it more testable with finer granularity. If you don't know much about refactoring, you should get a book or two on this as well. Perhaps the classic Refactoring by Martin Fowler.
Alister
+1  A: 

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 !

Matthieu
Yes, it is often difficult to write unit tests for legacy code. But it is possible with you refactor your code. There are many books that cover this and an excellent one is Michael Feather's "Working Effectively with Legacy Code".
Bruno Rothgiesser
+2  A: 

This Question might be useful to you.

Chris Huang-Leaver
+8  A: 

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.

Samuel Carrijo
I totally agree, thanks for your comments. Our old Delphi application (it started around 1999) was not written with testing in mind. Probably it will never be good unit testing for it as it require so much time to write.But when we start with the new C# application we don't want to make the same mistake again.
Roland Bengtsson
+2  A: 

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: http://stackoverflow.com/questions/293755/what-is-your-favorite-delphi-mocking-library

Pierre-Jean Coudert