如何根据TDD处理未来的需求
|
虽然最近在项目中尝试采用更多TDD实践,但我遇到了涉及未来需求的测试情况,这让我对其他人如何解决这个问题感到好奇.
比方说,我正在开发一个名为SuperUberReporting的应用程序,当前版本是1.4.当我正在开发要包含在SuperUberReporting 1.5中的功能时,我编写了一个新文件导出功能的测试,该功能允许将报告结果导出为CSV文件.在编写该测试时,我发现支持导出到某些其他格式的功能将针对更高版本的1.6,1.7和1.9,这些版本记录在问题跟踪软件中.现在我面临的问题是我是否应该为这些其他格式编写测试,还是应该等到实际实现这些功能？这个问题涉及一些关于TDD的更基本的东西,我想更广泛地提出这个问题. 只要需求已知,或者需求的稳定程度能否以某种方式确定是否应该编写测试,是否可以预先编写测试？ 更一般地说,应该在多长时间内编写测试？编写一个将失败两年的测试是否可以实现该功能？如果是这样,那么如何组织他们的测试来分离需要通过的测试与那些尚未通过的测试？我目前正在使用NUnit进行.NET项目,所以我不介意细节,因为它们可能更好地演示如何完成这样的组织. 解决方法
如果您正确地进行TDD,您将拥有一个持续集成服务器(类似Cruise Control或TeamCity或TFS),它可以构建您的代码并在每次登记时运行所有测试.如果任何测试失败,则构建失败.
所以不,你不要提前写测试.您为今天的工作编写测试,并在他们通过时签入. 失败的测试是噪音.如果你有失败的测试,你知道失败了,你会发现另一个(合法的)失败已经很难进入.如果你努力让所有的测试都通过,那么即使是一次失败的测试也是一个很大的警告标志 – 它告诉你是时候放弃一切并修复那个bug.但是如果你总是说“哦,没关系,我们总会有几百次失败的测试”,那么当真正的错误进入时,你就不会注意到了.你否定了进行测试的主要好处. 此外,现在为多年来不会工作的东西编写测试是愚蠢的.你现在正在推迟你应该做的事情,如果未来的功能被削减,你就会浪费工作. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |