尽管在编程行业中首字母缩写词的总数可能已经超过了在无月夜空上可以观察到的星星的数量,但只有一部分得到了普及和认可。 TDD肯定属于这个组。 从众多会议演讲,书籍,播客和博客文章来看,测试驱动开发是一种广为人知的技术,这一事实是不可否认的。 但是,当您考虑采用和实际使用时,实际情况可能会有所不同。 在本文中,我们将研究候选人在几次进行的技术面试中提出避免使用TDD的不同原因,并试图证明他们是否构成真正的障碍。
1.“管理不允许我们”
这里可能要问的问题是,为什么管理层决定开发人员是否应该使用TDD。 医生会问医院主任是否允许他使用医用手套? 当然不是,因为他使用它们来保护自己。 他也没有咨询他开给病人的每种药物。 作为专家,他被允许在问责制方面做出自己的决定。
同样,开发人员可以查看他们的工具集和技术。 您的目标是有效交付软件,而作为专业人员,您有责任找到实现方法。 没有什么可以阻止您在小功能上进行试运行以评估该技术是否对您有用,或者更像是球和链。
非技术经理实际上无法掌握TDD的全部含义。 他们中的许多人将“测试”与“质量分析”这个词联系在一起,并且由于许多组织中都有专门的质量检查人员来从事这项工作,因此他们不理解为什么开发人员应该重复他们的工作。 试图解释差异是没有意义的。 添加新功能后,您可能不会向经理解释选择了哪些数据结构来完成任务,因为这不是他们感兴趣的详细信息级别。TDD属于同一级别。
2.“没有足够的时间编写测试”
第二个借口(不仅适用于TDD,而且适用于所有类型的自动化测