增加可测试性，使用Bold编写Delphi框架 [英] Increasing testability, when coding with Bold for Delphi framework

问题描述

背景
我在7名开发人员和2名在物流系统上工作的测试人员的团队工作。
我们使用Delphi 2007和modeldriven开发，使用大胆的Delphi 作为框架。
该系统目前已经生产了约7年，拥有大约1,700万行代码。
我们在4-5周之后发布到生产，几乎每个版本之后，我们必须为我们没有发现的错误做一些补丁。这当然是对我们和客户的烦恼。

Background I work in a team of 7 developers and 2 testers that work on a logistics system. We use Delphi 2007 and modeldriven development with Bold for Delphi as framework. The system has been in production about 7 years now and has about 1,7 millions lines of code. We release to production after 4-5 weeks and after almost every release we have to do some patches for bugs we don’t found. This is of course irritating both for us and the customers.

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

Current testing The solution is of course more automatic testing. Currently we have manual testing. A Testdbgenerator that starts with an empty database and add data from the modelled methods. We also have Testcomplete that runs some very basic scripts for testing the GUI. Lack of time stop us from add more tests, but scripts is also sensitive for changes in the application. For some years ago I really tried unit testing with DUnit, but I gave up after some days. The units have too strong connections.

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

Unit testing preconditions I think I know some preconditions for unit testing:

• 编写一些做一件事的小方法，但做得很好。


• 不要重复你自己。 li>
  
• 首先写出失败的测试，然后编写代码，以便测试通过。


• 单元之间的连接松动。

• Write small methods that do one thing, but do it well.
• Don’t repeat yourself.
• First write the test that fails, then write the code so the test pass.
• The connections between units shold be loose. They should not know much about each other.
• Use dependency injection.

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

Framework to use We may upgrade to Delphi XE2, mainly because of the 64-bit compiler. I have looked at Spring a bit but this require an update from D2007 and that will not happen now. Maybe next year.

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

The question Most code is still not tested automatically. So what is the best path to go for increasing testability of old code ? Or maybe it is best to start writing tests for new methods only ? I’m not sure what is the best way to increase automatic testing and comments about it is welcome. Can we use D2007 + DUnit now and then easily change to Delphi XE2 + Spring later ?

编辑：关于手动测试的当前测试方法克里斯称它为打破它，尝试打破它。

About current test methodology for manual testing is just "pound on it and try to break it" as Chris call it.

推荐答案

你想要Michael Feathers的书， 有效地使用旧版代码 。它显示了如何将（单位）测试引入到未写入可测试性的代码中。

You want the book by Michael Feathers, Working Effectively with Legacy Code. It shows how to introduce (unit) tests to code that wasn't written with testability in mind.

某些章节以开发人员为什么为借口命名测试旧代码很难，它们包含案例研究和建议的方法来解决每个问题：

Some of the chapters are named for excuses a developer might give for why testing old code is hard, and they contain case studies and suggested ways to address each problem:

• 我没有太多时间必须更改


• 我无法在测试工具中运行此方法


• 此类太大，我不希望获得任何更大的


• 我需要更改一个怪物方法，我无法为其测试。

• I don't have much time and I have to change it
• I can't run this method in a test harness
• This class is too big and I don't want it to get any bigger
• I need to change a monster method and I can't write tests for it.

它还涵盖了许多破坏依赖的技术;有些可能对你来说是新的，有些你可能已经知道，但是还没有想过要使用。

It also covers many techniques for breaking dependencies; some might be new to you, and some you might already know but just haven't thought to use yet.

这篇关于增加可测试性，使用Bold编写Delphi框架的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！