如何应对不进行单元测试数据转换的借口？
我正在管理一个开发架构团队，该团队相当专注于支持许多不同的开发团队之间的测试实践。其中一个团队正在使用 Contentmaster 进行相对简单的数据映射/转换。
有一组规则记录了应执行的映射。如今，没有任何自动化方法可以测试映射是否“正确”。我们建议团队通过创建一个简单的测试框架来测试各个映射，然后在每次部署之前一一测试转换规则，但他们有一个典型的担忧：
- 我如何知道我的测试或映射是否错误？
- 如果有人更改了映射并且我的测试失败了，会发生什么情况？
- 我该如何证明我为制作测试用例而花费的所有时间是合理的？
- 如果测试结果为假阴性（即不应该通过的时候却通过了）怎么办？
你能帮我回答其中一些问题吗？我熟悉这种针对自定义开发项目的测试，但是当涉及到这样的数据操作时，我很难回答。
I am running a development architecture team that is fairly focused on bolstering testing practices among a number of disparate development teams. One of those teams is using Contentmaster for relatively simple data mapping/transformation.
There are a set of rules that document the mappings that should be performed. Today, there isn't any automated way of testing that the mappings are "correct." We suggested that the team test individual mappings by creating a simple testing framework and then testing the transformation rules one by one before every deployment, but they have the typical concerns:
- How do I know if my test or the mapping is wrong?
- What happens if someone changes a mapping and my test breaks?
- How am I supposed to justify all the time I need to spend in order to make the test cases?
- What if a test yields a false negative (i.e., passes when it shouldn't)?
Can you help me answer some of these questions. I am familiar with this kind of testing for custom development projects, but I'm having a harder time answering when it comes to data manipulation like this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
1 - 我如何知道我的测试或映射是否错误？
截至今天，您如何知道映射是正确的？需要有人调查这是否是一个问题。最好是单元测试失败并且现在有人可以进行调查，而不是将其传递给 QA 甚至客户。
2 - 如果有人更改映射并且我的测试中断，会发生什么？
它们不是您的单元测试，而是单元测试。谁破坏了构建，谁就修复了构建。每个人都应该在签入之前运行所有单元测试，并且应该在每次签入时由 Hudson 或类似的。
3 - 我应该如何证明我需要花费所有时间来制作测试用例？
我个人发现 TDD 比正常开发快得令人不安。即使速度相同，在开发人员/预 QA 级别查找错误所节省的时间几乎会立即收回成本。
不要浪费时间编写单元测试来确保工作代码正常工作。仅在以下情况下添加/更新单元测试：1) 更改功能，2) 添加新功能，3) 修复错误。
再加上稍后，当您返回并重构时，您会知道您并没有严重破坏代码。
4 - 如果测试结果为假阴性（即不应该通过的时候却通过了）怎么办？
这是不争的事实。 Bug 会被错过。仅仅因为单元测试可能会错过错误，并不会使单元测试失效。我的意思是，如果 QA 漏掉了一个 bug，你会解雇 QA 部门吗？单元测试的目的是减少开发团队漏掉的错误数量。这样，QA 就可以专注于更严重的问题。
如果发生这种情况，您唯一能做的就是返回，更新单元测试，然后修复代码。
单元测试不是灵丹妙药，但它在开发中的价值是无价的。
1 - How do I know if my test or the mapping is wrong?
As of today, How do you know the mapping is right? Someone will need to investigate if this is a problem. It's better that a unit test fails and someone can investigate now, instead of passing it to QA or even the client.
2 - What happens if someone changes a mapping and my test breaks?
They aren't your unit tests, they're the unit tests. He who breaks the build, fixes the build. Everyone should be running all the unit tests before checking in and they should be run automatically on every check-in by Hudson or similar.
3 - How am I supposed to justify all the time I need to spend in order to make the test cases?
I personally have found TDD to disturbingly faster than normal development. Even if it was just the same speed, the amount of time saved by finding bugs at the developer/pre-QA level will pay for itself almost instantly.
Don't waste time writing unit tests to make sure working code works. Only add/update a unit test if you are: 1) changing functionality, 2) Adding new functionality, 3) fixing a bug.
Plus later on, when you go back and refactor you will know that you have not broken the code severely.
4 - What if a test yields a false negative (i.e., passes when it shouldn't)?
This is a fact of life. Bugs will get missed. Just because the unit test can miss bugs, doesn't invalidate unit testing. I mean, if QA missed a bug would you fire the QA department? The purpose of unit testing is to reduce the number of bugs which escape the development team. This way, QA can concentrate on more serious issues.
If this happens, the only thing you can do is go back, update the unit test and then fix the code.
Unit testing isn't a silver bullet, but it is invaluable in development.
我不认为数据转换与任何其他组件不同 - 它需要像其他任何组件一样进行测试，并且这些问题的答案与任何其他测试相同。测试的投资金额当然应该与失败的成本或后果相关，这是有时被遗忘的事情：某些环境中的某些错误在上线后确实更便宜地检测和修复。我偶尔会看到一些项目进行了不必要的测试，但相反的情况更为常见。
我对“单元测试”这个术语持保留态度——我见过人们对系统的微小组件进行测试而得意忘形，比如类的单个方法或样式表中的单个模板。这可能是低效的，特别是如果测试“永久”维护并在每个构建上运行。有时在建造桥梁时需要脚手架，一旦桥梁建成，您就可以安全地将其存放起来。我更喜欢大多数测试应该使用系统用户可用的接口：这样可以最大限度地减少由于系统内部更改不影响其外部行为而导致测试失败的情况。
I don't think data transformation is different from any other component - it needs to be tested just as much as anything else, and the answers to these questions are the same as for any other testing. The amount of investment in testing should of course be related to the cost or consequences of failure, which is something that is sometimes forgotten: some bugs in some environments really are cheaper to detect and fix after you go live. I've occasionally seen projects that do more testing than necessary, but the opposite is far more common.
I have reservations about the term "unit test" - I've seen people get carried away with testing tiny components of the system, like individual methods of a class or individual templates in a stylesheet. That can be unproductive, especially if the tests are maintained "in perpetuity" and run on every build. Sometimes you need scaffolding while the bridge is being built, and you can safely put it in storage once the bridge is standing. I prefer that most of the tests should use interfaces that are available to users of your system: that minimizes the occasions when a test will fail because of changes to the internals of the system that don't affect its external behaviour.