开发后测试的陷阱是什么? [英] What are the pitfalls of test after development?

问题描述

最近我被分配到一个已经在进行中的项目.这是TDD环境.每个人都遵循代码单元测试优先和实现代码之后的正确原则.但是这对夫妇反其道而行之，先实现代码，后进行单元测试.

Recently I was assigned to a project which was already in its midway. It was TDD environment. Everyone was following right principle of Code Unit Test First and Implementation code later. But couple were doing in reverse, implementation code first and unit test later.

尽管在辩论中他们说两种方式都很相似.

Though on a debate they say either way its similiar.

如果先执行代码，然后执行单元测试，可能会出现什么问题?

What are potential issues may arise if implementation code first and unit test later is followed?

推荐答案

• 过度设计 - 您编写的代码可能比实际需要的多.
• 偏差 - 您可以编写测试来测试您的实现而不是需求.
• 测试不会推动您的设计 - 测试可以表明设计改进.随着时间的推移，您的设计可能会变得僵化，并且不愿意改变.
• 放慢速度 - 您的实现可能存在可测试性问题，只有在您尝试编写测试时才会出现这些问题.到那时，您可能会倾向于混杂一些东西，因为现在测试阻碍了您实现下一个功能.尝试对无法测试的 blob 进行单元测试令人沮丧.更多情况下，您最终会得到不彻底的测试(测试哪些是简单的，然后继续).
• 可能不会编写测试 - 一旦您的实现准备就绪并且您已经手动验证它可以工作，就会倾向于跳过无聊的单元测试并跳到有趣的部分……编写更多代码.随着时间的推移，未经检验的混乱.

如果不够明显，请先测试 FTW！

If it isn't obvious enough, test-first FTW!

这篇关于开发后测试的陷阱是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！