我们最近雇用了一个“发布经理”，他基本上只是建立一个项目管理系统并查看所有进入的项目，并确保它们具有所有文档。显然，要使SOX符合要求，即使他的头衔和职务说明似乎并不一致，也必须拥有一份。他现在要寻找的东西之一（如果缺少该建议，则拒绝该建议）是一个测试文档：分析师提出了一系列步骤，以测试他们所拥护的新功能或错误修复。我不会讨论文档的质量，但是至少其中大多数不是“部署到测试环境，分析师到测试”。让我们假设它们足够好，足以给某人至少一个快乐的路径测试。
这被认为是TDD吗？我想我一直以为TDD意味着您必须在类之前编写一个单元测试，或者在两个模块之间编写桥接代码之前编写一个集成测试。
现在，我不想陷入“我们很敏捷！”的境地。陷阱。我认为参加会议讨论我们是否确实在进行TDD是很愚蠢的。但是我认为重要的是能够将我们正在做的事情与其他人所学到的教训保持一致。如果我们正在做（一般人所说的）TDD，那么我们有理由从针对执行TDD的团队的建议中受益。 br />
是否需要将TDD强制进行的测试自动化？
我们是否正在执行一般社区所谓的TDD？
不管我们是否“存在”，是否都在此处表示一些危险信号，以便使我们与TDD社区更加一致？ br到目前为止，看来，是的，您确实需要自动测试才能成为“ TDD”。因此，也许有一个后续问题是将有多少TDD转换为“仅手动测试”环境？
#1 楼
TDD通常是开发人员首先编写单元测试而设计的代码。开发人员和质量检查人员对待测试概念的方式存在根本差异。将单元测试视为代码契约会更有用。这些将随时间更新和更改，这是主要区别。对于质量检查人员来说，测试一旦成功就应该一直有效，除非已明确删除该功能。对于开发人员而言，只要覆盖测试的代码，就可以更新/修改测试。这并不意味着单元测试没有任何作用。它们非常适合测试业务规则，也非常适合于通知开发人员给定方法的工作或应做的事情。单元测试通常会在发现涉及不同区域之间交互的错误时进行分解。测试文档通常是测试方法的概述和要涵盖的领域。然后创建具有测试步骤的测试计划。
应针对每个构建版本运行单元测试，以使其达到任何实际目的。
成功运行后，应对测试计划进行自动化检查。通常，您认为最初需要测试的并不是事实证明随着时间的推移会需要测试。我认为诀窍是为给定的功能制定良好的测试计划，然后在功能完成后配对测试用例，将功能的“核心”测试用例添加到回归中。
评论
这很有趣，但是实际上我们并没有在开发环境中进行构建。我们...我们将代码发送到各种系统，并在生产环境中进行编译。这是我要更改的过程的另一方面：-)
–corsiKa♦
2011-10-20 13:28
如果代码从未在生产环境中构建过，您怎么知道它甚至可以以某种方式编译，更不用说工作了？
– Ardesco
13年8月22日在13:19
#2 楼
从最真实的意义上来说，TDD正是Aruna所描述的。开发人员编写自动化的单元测试，观察测试失败，然后继续编写单元测试旨在测试的代码，进行编码直到通过，然后重构，同时保持核心单元测试。理想情况下（至少在我的世界中），所有测试也应组织在测试运行器中的套件中，例如JUnit（没有Java经验，但是，我似乎还记得您说过您在自己的Java上使用过Java）公司）。这样，您始终可以查看所做的更改，是否在测试之前的任何以前的代码中创建了错误，然后再进行测试。
没有真正的危险信号我可以看到（也可以抵抗流感和发烧，所以我可能错了），但是，如果您要研究JUnit或任何其他xUnit，您是否认为可以编写快速测试来测试每种方法？您是否真的认为需要更长的时间？对于单元测试和一般的TDD，通常不需要那里有很多框架。如果每天只花一个半小时到一个小时的额外时间来编写测试，而您自己的输出最终变得更可靠且符合客户的规格，您的经理会介意吗？
根据您的编辑进行编辑：在我个人看来，尽管TDD不一定会在其他人的头脑中，但它是自动化的。编写代码后手动测试代码只是一个好习惯。但是，如果您确实想采用TDD的动议并将其应用于手册中，则可能会发现即时代码有所改进。
准确写下您要执行的代码
编写代码
确保代码完全按预期运行。
有利的一面是，您可以将这些测试提供给变革支持者。 。
评论
实际上，最需要爱的项目是In Progress ABL。我所遇到的Java问题主要是针对我的辅助项目的：-)我知道这样一个事实，即自动化测试不会与管理层一起进行，因为这是一笔太大的投资。但是他们也说他们想要TDD。但这给了我一些见解，我将针对这些见解进行更新。
–corsiKa♦
2011年10月17日，下午1:26
回复：您的编辑。您的积极态度实际上是所有这一切的成因:-)现在，拥护者们被迫为开发人员创建文档。因此，他们写了这个文档，说明了新功能或新功能应该做什么，我们可以按照该文档进行操作。这也有助于阻止他们改变主意：-)而且不利之处很大，因为如果他们想再次使用相同的功能，只是功能的不同方面，他们不太可能通过第一个测试，只专注于第二个。
–corsiKa♦
11-10-18在16:24
#3 楼
我曾经参加过“测试驱动开发”，这就是我们采用的方法。开发人员甚至在开始编码之前就开发了自动化的单元测试。假设有18种测试可以验证付款方式。在他编写代码之前，所有18个测试都将失败。编码完成后，他将确保所有18个自动化单元测试都通过。完成单元测试后，他会将测试移交给质量检查人员。我们在公司进行了自动化的单元测试。我不确定是否必须将其自动化。
评论
我真的无法想象非自动化的单元测试，或者非自动化的单元测试将完全有益。
– joshin4colours
2011年10月17日，下午3:21
大多数开发人员没有时间或兴趣进行自动化测试，他们选择手动进行单元测试。您是否要说使用TDD进行手动单元测试是没有好处的？如果是的话，我完全可以同你所说的保持联系。对于开发人员而言，在编码开始之前手动进行单元测试，然后再次重复执行相同的手动单元测试，直到编码完成后所有测试均通过，这没有意义。它效率低下，无法带来很多收益。
– Aruna
2011年10月17日下午5:47
那或多或少是我的意思。单元测试的整体思想是，它们可以在单元级别对代码进行快速检查。使它们自动化可以使它们更加高效和标准化。进行手动单元测试可能会非常低效，更不用说标准化了（特别是如果开发人员处于时间压力之下）。
– joshin4colours
2011-10-17 17:54
说“大多数开发人员没有时间或兴趣来进行测试自动化”有点狭narrow，而且我所知道的大多数开发人员与5年前相比肯定有不同的观点。不对单元代码进行单元测试的开发人员充其量是无能的。另外，手动单元测试到底是什么？ “手动单元测试”是矛盾的。
– Bj Rollison
2011-10-20 15:47
很高兴知道开发人员正在改变他们对测试自动化的看法。当他们被要求进行测试自动化时，我已经看到DEV变得沮丧。它应该改变，我很高兴它不会在所有地方发生。
– Aruna
2011年10月20日在20:22
#4 楼
TDD都不是手动测试。 “驱动”部分的整个想法是，您获得了一组测试，它们在每次对源代码进行更改时都会运行，以保持稳定性并防止出现回归问题。但是，测试不需要是单元测试。如果您愿意，它们可以是例如自动化的UI测试。
#5 楼
这是一个非常有趣的问题，但似乎起点不是“什么是TDD？”。但是更像是“我们怎么能做不出脚踩脚的可能性呢？”您可能会翻阅“ Joel on Software”一文。通常，它是有关软件开发最佳实践的规范参考。它是用Bubble 1.0编写的，但今天这些概念仍然有用。
评论
我对Joel测试非常熟悉，我的公司得分为3.5分。 （按顺序，是否否是否否否否是否（是，但不是专门的）否。）但是，它实际上只是一种可以比较各个团队的机制。另外，我们不是软件公司，而是制造公司，这使我们对那些不那么“最佳实践”的人产生了兴趣。因此，我试图找到可以满足政府要求或完全包含在开发中的小流程变更，以规避公司惯性（这是一个严重因素）。
–corsiKa♦
2011-10-20 23:25
评论
你写了一个好问题，glowcoder。如果您要问您的管理链，他们特别想摆脱今天没有得到的TDD，您认为他们会怎么说？您是否认为他们确实想要TDD，仅此而已？还是您认为他们对他们认为对TDD正确的一系列事情更感兴趣？好吧，我认为（正如您可能从我的其他帖子中得出的那样）是他们不确定自己想要什么。他们在制造业中赚了数十亿美元，在他们的制造模式下，他们曾经经历过的每个内部流程都表现出色。但这并不能随技术而定，它最终会赶上技术。但是逆转20年的思考过程很难。因此，他们去参加会议并收集想法，但不完全确定如何将所有部分组合在一起。因此，我想说的是他们想要的只是质量更高的软件。我不确定他们是否可以提供更多细节。
我知道我不想要什么证书，上面写着“我们正在TDD！是的！”相反，我想在任何可能的地方都应用所有可能的好的原则。尽管我想说服他们进行自动化测试，但我愿意接受更好的手动测试。我的意思是，分析师的测试文件是新的。我的主要目标是在给定的环境下找到一些可以提出的想法。