Question

I have a Delphi application that has many dependencies, and it would be difficult to refactor it to use DUnit (it’s huge), so I was thinking about using something like AutomatedQA’s TestComplete to do the testing from the front-end UI.

My main problem is that a bugfix or new feature sometimes breaks old code that was previously tested (manually), and used to work.

I have setup the application to use command-line switches to open-up a specific form that could be tested, and I can create a set of values and clicks needed to be done.

But I have a few questions before I do anything drastic… (and before purchasing anything)

1. Is it worth it?
2. Would this be a good way to test?
3. The result of the test should in my database (Oracle), is there an easy way in testcomplete to check these values (multiple fields in multiple tables)?
4. I would need to setup a test database to do all the automated testing, would there be an easy way to automate re-setting the test db? Other than drop user cascade, create user,…, impdp.
5. Is there a way in testcomplete to specify command-line parameters for an exe?
6. Does anybody have any similar experiences.

Answer 1

I’m in a similar situation. (Large app with lots of dependencies). There is almost no automated testing. But there is a big wish to fix this issue. And that’s why we are going to tackle some of the problems with each new release.

We are about to release the first version of the new product. And the first signs are good. But it was a lot of work. So next release we sure need some way to automate the test process. That’s why I’m already introducing unit tests. Although due to the dependencies, these are no real unit tests, but you have to start somewhere.

Things we have done:

• Introduced a more OO approach, because a big part the code was still procedural.
• Moved stuff between files.
• Eliminated dependencies where possible.

But there is far more on the list of requirements, ensuring enough work for the entire team until retirement.

And maybe I’m a bit strange, but cleaning up code can be fun. Refactoring without unit tests is a dangerous undertaking, especially if there are a lot of side effects. We used pair programming to avoid stupid mistakes. And lots of test sessions. But in the end we have cleaner code, and the amount of new bugs introduced was extremely low.

Oh, and be sure that you know this is an expensive process. It takes lots of time. And you have to fight the tendency to tackle more than one problem in a row.