我目前正在开发一个项目，该项目使用的技术包括Silverlight，WCF，EnterpriseLibrary，Unity，LinqToSql，NUnit，.Net 3.5中的RhinoMocks
我正在培训一名新的开发人员，他对VB脚本和SQL有一定的经验，但没有接触.Net
几乎100％的代码库都有单元测试覆盖率，但似乎让新开发人员开始编写单元测试太多了，有足够的东西继续探索，没有增加单元的混乱测试和嘲笑。
他被分配了为解决方案实施新功能的任务，这些功能贯穿于每个层，从用户界面到数据库，并且一如既往有强烈的客户需求，以尽快将该功能投入生产。
您认为最好的方法是让某人加快速度？
答案 0 :(得分：19)
由于完全没有.NET经验，我会说在学习.NET有点多的同时围绕TDD。
有些拥有丰富.NET经验的人对TDD有足够的时间 - 它需要对基本的开发方法进行真正的改变。从VB到.NET并不难，但确实需要时间。
你真的想避免混淆--TDD是良好的开发方式，但它不是 方式和TDD！= .NET开发。事实上，它是完全正交的 - 试图同时教授新方法和新平台？我看不出这是个好主意。
答案 1 :(得分：7)
如果是我，我会和他和TDD配对一下。你编写了一些测试，他编写的代码使其工作，然后编写下一个测试并编写代码使其工作，等等。
有趣，让您快速体验，节省时间和金钱。
答案 2 :(得分：3)
对于没有经验的开发人员来说，单元测试看起来就像是将所有代码加倍。这是一个巨大的转折。
你真的需要让他们失败才能真正体会到单位测试的好处。
答案 3 :(得分：2)
考虑到已经有很多东西需要学习，我担心谈论TDD和自动化测试可能有点“太多”：如果你的新开发者不知道如何开发，他将不知道如何开发测试 - 他写的测试可能不会真正有用。
在你的情况下，我会让他编码几天/周，手工测试;当他开始理解你的代码库时，我会花一些时间与他进行一些配对编程：这将是一个引入自动化测试的好时机，并同时审查他的代码/评论/改进。 / p>
答案 4 :(得分：2)
我会说是 - 整个测试点都是集中在一个区域。它实际上有助于清除头部，而不是像学习NUnit需要10多分钟。当然，他可能会在一段时间内对这些概念进行一些努力，但是一点点努力工作和大量配对应该比没有TDD提供的指导更容易克服这些任务。
答案 5 :(得分：2)
他被分配了任务 实现解决方案的新功能 从UI切入每一层 到数据库，和往常一样 强大的客户需求得到了 尽快投入生产 可能的。
您认为最好的方法是什么？ 是为了让某人接受 速度ω
如果您提供了信息，那么他可能永远不会加快速度。教他如何你做这项工作。
作为团队的初级成员，“强烈的客户需求”（即时间表的问题）不是他的问题：团队负责人和/或项目经理应该避免他
您可能需要对客户进行培训：引入一位以前没有技术经验的新团队成员是一项值得长期投资的投资。
在短期内，您（或客户）可能很少或根本没有立竿见影的好处：因为他很慢（学习），并且花了一些时间（不是独立的）。
IMO你应该：
不要让他赶时间（相反，让他在你期望他快速完成之前让他学会做好）
专注于确保其输出不会降低项目可交付成果的整体质量所必需的任何内容（即，您当然应该教他，并确保他的日程安排允许，无论开发人员测试和质量保证方法如何，开发商的期望）
那就是I don't think that unit test are always necessary。但是在一个新的（没有经验的）程序员和的情况下，你显然已经确定100％的单元测试覆盖率对于这个项目是正确的，我发现很难理解你为什么要为他改变你的开发过程（除非这些他被分配的功能有一些与其他功能不同的时间表/质量要求）。
答案 6 :(得分：1)
听起来新开发人员已经开火了。
似乎你应该让他加快速度并开始分享他的功能，给他一些时间来处理它们，一旦他感到舒服......然后开始他进行单元测试。
答案 7 :(得分：1)
我会开始简单 - 将作业分成逻辑部分，然后与他配对，直到他掌握当前部分。我不认为完全沉浸在TDD中会有效，直到他达到很好的舒适程度，但这并不意味着你不能让他接受单元测试等等。
也许，作为准备工作的一部分，您可以编写一些完成分配任务所需的测试。当他正在解决这个问题时，你可以引导他走向一般的解决方案，使用测试（“红灯坏！”）来证明他的想法在哪里。
从那里，你可以在“导航”时“开车” - 他为你定义了所需的功能，你可以质疑他如何测试这个功能。开始和他一起写测试，以便他可以看到测试和产品之间的联系，然后让他慢慢接管。
希望，如果他身体健康，他将能够从头开始掌握概念，然后扣除如何编写自己的测试（当然，在你的指导下！）。我认为最后一步是将他扔进池中并迫使他编写测试，作为定义他想要编写的功能的一部分。
这可能不是一个快速的过程，但希望这将为他提供TDD /单元测试的良好基础
答案 8 :(得分：1)
如果不是现在呢？我认为我在本次讨论中看到的推理线是不进行单元测试的借口。永远都会有比我更好的程序员，明天我永远是一个更好的程序员。
即使暗示“只有超级忍者开发者”应该进行单元测试也是错误的信息，特别是如果你重视100％的覆盖率统计数据。
单元测试教导一个被测试代码的API向后和向前，而不会让开发人员通过对生产代码进行危险的未经测试的更改来学习。
至于复杂性问题 - 复杂的代码是复杂的代码。没有单元测试的牛仔开发并不简单。
答案 9 :(得分：0)
我想说启动程序员支持。了解用户问题并查找错误，故障查找和修复将教会新程序员如何将应用程序组合在一起，编写测试更多是关于新开发。
答案 10 :(得分：0)
如果你在你的测试区域有嘲弄，那么他就会有严重的问题需要理解。但是，如果您要为他分配更简单的任务（他不必关心Mockery）并学会找出“我的代码应该做什么？”这应该是可行的。
答案 11 :(得分：0)
让其他人编写单元测试并让他编写代码以使测试通过。一旦他对此感到满意，你就可以向他介绍创建测试。
答案 12 :(得分：0)
我要做的是说：
“我们在这里使用TDD，您也会这样做，但首先我希望您对.NET环境感到满意。然后在几周内我们将坐下来编写几个单元测试代码。”
我认为这让他有时间消化。