以编程方式测试代码：程序员还是其他人？

Question

所以情况就是这样 - 我老板的一句话：“我们需要专注于编程。[...]最后我想写好软件而不是陷入困境通过测试。“在我们有3个月的令人生畏的错误列表并且最近指定一名非程序员用Selenium框架编写Web测试之后，我们就说了。

我的老板非常害怕单位测试（当他放慢开发人员的速度时，他看不到成本效益）。您对Web测试和程序测试有何看法？它们应该由（或）程序员编写还是重要？我的想法是编写好的软件的一部分是编写测试？他是微软象牙塔式的人，所以微软（或一般的好文章）推出的有利于设计测试的任何资源都会有所帮助。

Answer 1

这就是我的所作所为。

1. 无论如何，我写了测试。

2. 我在编写测试后编写了代码。

3. 代码坚如磐石（大部分）没有错误（达到了我的能力范围。）

我从未告诉任何人我在做TDD。除非他们问。

事实证明，TDD实际上比试图设计某些东西更快，编码并希望它有效。

一些事情包括一个额外的步骤0：“技术峰值”，看看事情是如何运作的。接下来是一些测试开发，以练习尚未编写的真实软件。

在开始设计方面，我有点落后于时间表。由于我的设计是“为该设计设计和编写测试”，而其他一些人设计的是“一些聪明的想法，但没有真正的证据。”有些人可以很好地在纸上设计。我不能。但我可以设计测试。

在整理代码方面，我通常都遥遥领先。因为 - 当我完成编码 - 所有测试都通过了。

Answer 2

Code Complete是一本书，是Microsoft Collection的一部分。它包含提倡同行评审和刷新单元测试作为概念的建议。单元测试并没有太深入细节，但它可能使他热衷于这个想法，你可以从那里进一步探索这个主题。

最终你需要一个直接参与自动化测试的程序员...我的意思是，这就是定义。

单元测试最有效地由最熟悉它们所编写的子系统的人编写，当选择其他人编写单元测试时，需要时间来提升，并且他们可能会错过未记录的意图或明确的意图在代码中可能导致更糟糕的覆盖范围。另一方面，子系统的所有者也可能对某些缺陷视而不见（但这是同行代码审查的目的！）

---

其余部分实际上只是关于道德的闲谈，但重要的是要考虑。

当管理层做出愚蠢的决定时，有些人喜欢尝试“偷偷溜进去”。这让我不仅感到不安，而且对那些程序员也很谨慎。我理解动机，我认为我们都在那里，但最终你应该教育而不是参与诡计。

管理在日程安排中发挥着重要作用，他们依靠您进行准确的估算和对正在完成的工作的一般理解。如果你填写你的估计来扫除地毯下的额外工作真的是一件好事吗？什么是一个简单的谎言变成了这个精心设计的骗局，你正在为直接参与帮助你的职业发展的人们发挥作用。

合法工作的流程和估算问题现在已成为一个棘手的道德问题。

我强烈建议你采取有计划的方法，说服你的经理通过理性，逻辑和吸引他对微软的热爱来看待你的观点。 ;）

从长远来看，如果你发现自己经常在编程过程的决策上做出决策（这对他们的决策来说真的不是他们的工作），那么最好能够完善这份简历并找到更好的工作。

程序员的一部分工作是教育那些专业知识较少的人。向你的经理解释这可能有助于打破他在这个问题上的一些智力障碍，并使他软化接受你对此事的建议。

Answer 3

我向全世界寻求“完成”的事情需要至少两个人验证。如果团队中的每个人都认为软件质量是每个人的工作，那么您并不总是需要团队中的软件测试人员。

如果您希望它高效，那么编写代码的开发人员应该编写测试，并且有人使用生产代码审查它们。如果你想要高效，那么当你在“配对的tdd”中编写代码时，他们会与某人配对并编写测试。

提醒经理，错误的成本会在发现的后期呈指数级增长。

Answer 4

我明白老板的来源。毕竟，程序员应该能够制作出“有效”的代码。但是，测试将无论发生什么，无论是单元测试，公司集成测试还是安装在客户之后。这些阶段中的每个阶段的错误都有不同的成本和后果，但是......

Answer 5

您经常会听到让其他人测试您的代码是一个好主意，因为他们可能会以不同方式解释规范。但是，为自己的代码编写测试的好处是，您知道它可能存在缺陷。

一种有效的方法可能是两者兼而有之：程序员编写自己的单元测试，专注于角落案例和其他人做一些功能测试，专注于更高级别的规范。

Answer 6

并非所有测试都是平等的，让我们来看看：

• 单元测试/ TDD。它很难反驳它，特别是它与“当它减慢开发人员的速度时看不到成本效益”相反，它更快。 S. Lott详细介绍了这些细节。
• 重点集成测试。与上面相同，它更快。无需通过完全集成的应用程序执行一系列步骤，以确定您刚刚编写的非常薄的集成代码层是否正常工作。当你认为你必须多次重复这种情况时，这是最糟糕的，当错误地与不同的进程紧密耦合时，情况会更糟。
• 完整的系统测试。有了上述内容，您只需要知道所有部分是否正确连接，以及UI是否按预期工作。对于早期，您需要进行一些非常快速编写的测试;将其与人们手动移动的次数（包括你自己）进行比较，你就有了胜利者:)。对于后者而言，有些事情很难通过自动化测试来捕获，因此您不会将自动化集中在那些上。
• 探索性测试。这些仍然应该完成，希望在构建功能之前提出足够的想法，以避免此时进行额外的更改。

现在，QA通常会提出其他方案。这很好，但在自动化测试中以协作方式包含它是最好的。

一个真正的问题可能是当前的团队技能。代码越多，单元测试越难，现有代码通常没有单元测试，这通常是最糟糕的，但最初也使得开发人员更难以向前发展，因为开发人员不熟悉如何设计松散耦合/高代码凝聚力代码。它需要完成，但要注意这一点，因为成本会转移到某个地方（对团队成员或公司来说）。

Answer 7

要创建一个好的测试套件，需要花费很多精力;这将花费比预期更长的时间。

在这方面，你的老板是对的。

但是，如果您计划扩展您的产品（添加功能）或网站（添加页面和javascript代码），那么您需要在以后创建该套件。

Answer 8

你可以指出，自VS2005以来，unit testing已构建到.Net框架中。