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

Question

情况是这样的——引用我老板的话：“[...]我们需要专注于编程。[...] 归根结底，我想编写出优秀的软件，而不是陷入测试的泥潭。”这是在我们经历了 3 个月的一系列令人畏惧的 bug 并最近指定一名非程序员来编写之后说的。使用 Selenium 框架进行 Web 测试。

我的老板非常害羞进行单元测试（当它减慢开发人员的速度时，他看不到成本效益）。您对网络测试和程序测试的总体看法是什么？它们应该由（或）程序员编写吗？这很重要吗？我的想法是编写优秀软件的一部分就是编写测试？他是微软象牙塔里的人，因此微软提供的任何有利于设计测试的资源（或一般的好文章）都会有所帮助。

Answer 1

这就是我所做的。

1. 我还是写了测试。

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

3. 该代码是岩石固体的，并且（主要）不含错误（达到我能力的限制。）

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

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

一些事情包括额外的步骤0：一个“技术尖峰”，以了解事物的工作原理。接下来是一些测试开发，以行使尚未写的真实软件。

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

在完成代码方面，我通常很远。因为 - 完成编码后，所有测试都通过了。

Answer 2

代码完成是一本书，是Microsoft Collection的一部分。它包含提倡同行评审和刷牙作为一个概念的建议。它不会在单位测试中详细介绍，但是它可能会使他想到这个想法，您可以从那里进一步探索该主题。

最终，您需要一个直接参与自动化测试的程序员的人……我的意思是，从定义上讲。

Unit tests are most effectively written by the people who are most familiar with the subsystems they are written for, when someone else is chosen to write unit tests it takes them time to ramp up, and they may miss intention not documented or clear in the code这可能会导致覆盖范围更糟。另一方面，子系统的所有者也可能对某些缺陷视而不见（但这是Peer Code评论的目的！）

---

其余的实际上只是关于道德的闲置讨论，但要考虑的是重要的。

当管理层做出愚蠢的决定时，有些人喜欢尝试“偷偷摸摸地偷偷摸摸”。这不仅使我感到不安，而且对那些程序员有些警惕。我了解动力，我认为我们都去过那里，但最终您应该教育而不是参与构想。

管理层在调度方面起着重要的作用，他们依靠您进行准确的估计和对正在完成的工作的一般理解。如果您的估计量将额外的工作扫除地毯下，那真的是一件好事吗？一个简单的谎言变成了您在直接参与帮助您的职业进步的人们身上扮演的精心制作的骗局。

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

我强烈建议您采用您计划的方法来说服您的经理通过理性，逻辑和吸引他对微软的热爱来了解您的观点。 ）

从长远来看，如果您发现自己不断地在有关编程过程的决策方面进行管理（实际上不是他们做出决定的工作），那可能是最好的履历并找到更好的工作。

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

Answer 3

我认为，要“完成”某件事，需要至少经过两个人的验证。如果团队中的每个人都相信软件质量是每个人的工作，那么团队中并不总是需要软件测试员。

如果您希望它非常高效，那么编写代码的开发人员应该编写测试，并由某人使用生产代码来审查它们。如果您想要高效，那么与某人结对，他们在您以“配对 tdd”形式编写代码时编写测试。

提醒经理，越晚发现错误，其成本就会呈指数级增长。

Answer 4

我了解你的老板的来源。毕竟，程序员应该能够制定仅“有效”的代码。但是，测试 将要 无论如何，无论是单位测试，在公司中还是在客户安装之后进行集成测试。这些阶段的每个阶段的错误都有不同的成本和后果，但是...

Answer 5

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

有效的方法可能是两者的混合：程序员编写自己的单元测试，重点关注角落案例和其他人进行一些功能测试，重点是高级规范。

Answer 6

并非所有测试都相等地创建，让我们解决一些：

• 单位测试 / TDD。很难反对它，特别是与“他看不到成本降低开发人员的成本收益”的相反，它的速度更快。 S. Lott讨论了细节。
• 集中集成测试。与上面相同，它的速度更快。无需通过一系列整合应用程序贯穿一系列步骤，以找出您刚刚编写的非常薄的集成代码层是否有效。当您认为重复的次数很多次时，这是最糟糕的，甚至当错误地与不同的过程紧密结合时，它甚至更多。
• 完整的系统测试。有了以上的位置，您只想知道所有零件是否正确挂钩，以及UI是否按预期工作。对于较早的情况，您需要很快编写的一小部分测试；比较人们手动进行了多少次（包括您自己），您有了赢家:)。对于后来，有些事情很难通过自动化测试来捕捉，因此您不会将自动化集中在这些测试上。
• 探索性测试。这些仍然应该做到，希望在构建功能之前要提出足够多的想法，以避免在这一点上进行额外的更改。

现在，质量保证通常会提出其他场景。这很好，但是当在自动测试中以协作方式包含它时，最好。

一个真正的问题可能是当前的团队技能。单位测试越难以耦合，代码越大，对于没有单位测试的现有代码通常是最坏的，但是最初，这也使得不知道如何设计代码的开发人员更难前进。凝聚代码。它需要做到这一点，但要意识到这一点，因为成本将转移到某个地方（对团队成员或公司）。

Answer 7

为了创建一个良好的测试套件，这需要大量的努力。这将花费比预期的更长。

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

但是，如果您打算扩展产品（添加功能）或网站（添加页面和JavaScript代码），那么您需要在以后的时间进行创建套件。

Answer 8

你可以指出 单位测试 自VS2005以来，已内置在.NET框架中。