所以情况就是这样——引用我老板的话：“[...] 我们需要专注于编程。[...] 归根结底，我想写出好的软件，而不是陷入测试的困境。” 这是在我们有 3 个月的令人生畏的错误列表并且最近指定一个非程序员使用 Selenium 框架编写 Web 测试之后说的。
我的老板对单元测试非常害羞（当它减慢开发人员的速度时，他看不到成本收益）。您对 Web 测试和编程测试有什么看法？它们应该由（或）程序员编写还是有关系？我的想法是编写好的软件的一部分是编写测试？他是微软象牙塔式的人，因此微软提供的任何支持设计测试的资源（或一般的好文章）都会有所帮助。
这就是我所做的。
我还是写了测试。
我在编写测试后编写了代码。
代码坚如磐石，（大部分）没有错误（在我的能力范围内）。
我从来没有告诉任何人我在做 TDD。除非他们问。
事实证明，TDD 实际上比试图设计、编码并希望它能工作的东西要快。
一些事情包括一个额外的步骤 0：一个“技术高峰”，看看事情是如何运作的。接下来是一些测试开发，以练习尚未编写的真实软件。
在开始设计时，我有点落后于计划。因为我的设计是“为该设计设计和编写测试”，而其他一些人的设计是“用一些聪明的想法草草解决，但没有真正的证据”。有些人可以很好地在纸上设计。我不能。但我可以设计测试。
在完成代码方面，我通常遥遥领先。因为——当我完成编码时——所有的测试都通过了。
Code Complete 是 Microsoft 合集中的一本书。它包含提倡同行评审和将单元测试作为一个概念进行梳理的建议。它并没有对单元测试进行太多详细介绍，但它可能会使他对这个想法产生兴趣，并且您可以从那里进一步探索该主题。
最终，您需要一个直接参与自动化测试的程序员......我的意思是，这就是定义。
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这可能导致更差的覆盖范围。另一方面，子系统的所有者也可能对某些缺陷视而不见（但这就是同行代码审查的目的！）
其余的实际上只是关于道德的闲谈，但重要的是要考虑。
当管理层做出愚蠢的决定时，有些人喜欢尝试“潜入”构建。这让我不仅不安，而且对那些程序员有点警惕。我理解动机，我想我们都去过那里，但最终你应该教育而不是参与诡计。
管理层在日程安排中发挥着重要作用，他们依靠您进行准确的估算和对正在完成的工作的总体了解。如果你垫你的估计，扫除地毯下的额外工作，这真的是一件好事吗？一个简单的谎言变成了这个精心设计的骗局，你在直接参与帮助你的职业发展的人身上。
合法工作的流程和评估问题现在已成为一个棘手的道德问题。
我强烈建议您按照计划的方法来说服您的经理通过理性、逻辑来理解您的观点，并吸引他对 Microsoft 的热爱。;)
从长远来看，如果您发现自己在有关编程过程的决策上经常与管理层抗争（这确实不是他们的工作来做出决策），那么最好完善简历并找到一份更好的工作。
程序员工作的一部分是教育那些缺乏专业知识的人。向你的经理解释这可能有助于打破他在这个问题上的一些智力障碍，并软化他接受你对此事的建议。
我相信世界上要“完成”的事情需要至少有两个人验证。如果团队中的每个人都认为软件质量是每个人的工作，那么团队中并不总是需要软件测试员。
如果您希望它高效，那么编写代码的开发人员应该编写测试，然后有人使用生产代码对其进行审查。如果您想高效，请与某人配对，他们编写测试，而您在“配对 tdd”中编写代码。
提醒经理，错误的成本越晚发现越成倍增长。
我知道你的老板来自哪里。毕竟，程序员应该能够编写出“有效”的代码。但是，无论如何，测试都会发生，无论是在您的公司中进行单元测试、集成测试还是在您在客户处安装之后。这些阶段中的每一个阶段的错误都有不同的成本和后果，尽管......
您经常会听到让其他人测试您的代码是个好主意，因为他们可能会以不同的方式解释规范。但是，为您自己的代码编写测试的好处是您知道它可能有缺陷的地方。
一种有效的方法可能是两者的混合：程序员编写自己的单元测试，专注于极端情况，其他人进行一些功能测试，专注于更高级别的规范。
并非所有测试都是平等的，让我们回顾一下：
现在，QA 通常会提出其他方案。这很好，但是当它以协作方式包含在自动化测试中时，它是最好的。
一个真正的问题可能是当前的团队技能。代码的耦合度越高，单元测试就越难，这对于没有单元测试的现有代码来说通常是最糟糕的，但它最初也使得不知道如何设计松散耦合/高代码的开发人员更难前进凝聚力代码。它需要完成，但请注意这一点，因为成本会流向某个地方（对团队成员或公司）。
要创建一个好的测试套件，需要付出相当多的努力；这将需要比预期更长的时间。
在这方面，你的老板是对的。
但是，如果您计划扩展您的产品（添加功能）或网站（添加页面和 javascript 代码），那么您无论如何都需要在以后创建套件。
您可以指出，自 VS2005 以来，.Net 框架中已经内置了单元测试。