我正在运行一个开发架构团队，该团队非常注重在众多不同的开发团队中加强测试实践。其中一个团队正在使用Contentmaster进行相对简单的数据映射/转换。
有一组规则记录了应该执行的映射。今天，没有任何自动测试方法表明映射是“正确的”。我们建议团队通过创建一个简单的测试框架来测试单个映射，然后在每次部署之前逐个测试转换规则，但它们有典型的问题：
你能帮我解答一下这些问题。我对自定义开发项目的这种测试很熟悉，但是在这样的数据操作方面，我很难回答。
1 - 如何知道我的测试或映射是否错误？
截至今天，你怎么知道映射是对的？如果这是一个问题，有人需要调查。单元测试失败并且有人可以立即进行调查，而不是将其传递给QA甚至是客户端，这样做会更好。
2 - 如果某人更改了映射并且我的测试中断了会发生什么？
它们不是你的单元测试，它们是单元测试。打破构建的人，修复了构建。每个人都应该在办理登机手续之前运行所有单元测试，并且应该在Hudson或类似的每次办理登机手续时自动运行。
3 - 为了制作测试用例，我应该如何证明我需要花费的时间？
我个人发现TDD比正常开发更令人不安。即使速度相同，通过在开发人员/ QA级别之前发现错误所节省的时间也几乎可以立即收回成本。
不要浪费时间编写单元测试以确保工作代码有效。如果您是以下情况，则仅添加/更新单元测试：1）更改功能，2）添加新功能，3）修复错误。
再加上，当你回去重构时，你会知道你没有严重破坏密码。
4 - 如果测试产生假阴性（即不应该通过时）怎么办？
这是生活中的事实。虫子会被遗漏。仅仅因为单元测试可能会错过错误，不会使单元测试无效。我的意思是，如果QA错过了一个错误，你会解雇QA部门吗？单元测试的目的是减少逃避开发团队的错误数量。这样，质量保证可以专注于更严重的问题。
如果发生这种情况，您唯一能做的就是返回，更新单元测试然后修复代码。
单元测试不是一个灵丹妙药，但它在开发中是非常宝贵的。
我不认为数据转换与任何其他组件不同 - 它需要像其他任何组件一样进行测试，并且这些问题的答案与任何其他测试的答案相同。测试投资的数量当然应该与失败的成本或后果相关，这有时会被遗忘：某些环境中的某些错误在您上线后检测和修复的成本确实更低。我偶尔会看到那些测试不是必要的项目，但相反的情况则更为常见。
我对“单元测试”这个术语有所保留 - 我看到人们对测试系统的微小组件感到厌烦，比如类的单个方法或样式表中的单个模板。这可能是徒劳的，特别是如果测试是“永久性”维护并在每个构建上运行。有时您在建造桥梁时需要脚手架，并且一旦桥梁站立就可以安全地将其存放。我更喜欢大多数测试应该使用系统用户可用的接口：这样可以最大限度地减少测试失败的时机，因为系统内部的更改不会影响其外部行为。