单元测试 – 使用Delphi框架的Bold编码时,可以提高可测性

背景
我在7名开发人员和2名在物流系统上工作的测试人员的团队工作。
我们使用Delphi 2007和modeldriven开发与 Bold for Delphi作为框架。
该系统目前已经生产了大约7年，拥有大约1,700万行的代码。
我们在4-5周后才能发布，几乎每次发布之后，我们都要做一些我们没有找到的bug的补丁。这对我们和客户来说当然是令人不安的。

当前测试
解决方案当然是更自动的测试。目前我们有手动测试。一个Testdbgenerator，从一个空数据库开始，并从建模的方法添加数据。我们还有Testcomplete运行一些非常基本的脚本来测试GUI。缺乏时间阻止我们添加更多测试，但脚本对应用程序的更改也很敏感。几年前，我真的尝试用DUnit进行单元测试，但几天后我放弃了。这些单位的连接过强。

单位测试前提条件
我想我知道单元测试的一些先决条件：

写一些做一件事的小方法，但做得很好。
>不要重复你自己。
>首先写出失败的测试，然后写代码，以便测试通过。
>单位之间的连接松动。他们不应该彼此了解太多。
>使用依赖注入。

使用框架
我们可能升级到Delphi XE2，主要是因为64位编译器。
我已经看过Spring，但这需要从D2007更新，现在不会发生。或许明年。

问题
大多数代码仍然没有自动测试。那么为了提高旧代码的可测试性，最好的途径是什么？或者最好是开始为新方法编写测试？
我不知道什么是增加自动测试和评论的最佳方式是欢迎。我们现在可以使用D2007 DUnit，然后很容易地更改为Delphi XE2 Spring？

编辑：关于手动测试的现行测试方法，就像Chris所说的那样，只是“打破它，试图打破它”。