所以......我需要培训团队测试 - 可以在课程计划中使用C&C

lqui 发布于 2019-11-10 最后更新 2019-11-10 12:10 81 浏览

内容太长未翻译

已邀请:

psequi

赞同来自:

我试图在一个小团队(7-9程序员)中介绍TDD。讲座失败了。人们持怀疑态度,TDD听起来像蛇油。另外,总会有众所周知的威利。 最后,团队中的人员不是进行TDD,而是偶尔进行DDT(开发驱动测试):写入单元在代码之后进行测试,以确认它是否符合他们的意思。看起来完全失败,直到你意识到即使这种形式的开发人员驱动的QA比以前更好,因为即使它没有真正改进未来重访的代码,它也会削减已部署的错误。 然而,与您的设置相比,有一个关键的区别:推送不是来自管理层,它们只是让程序员自己决定。 讲座失败了,但我并没把所有鸡蛋放在一个篮子里。我为整个项目中使用的许多较小的,更集中的函数和类编写了一堆测试。那些小虫子你偶尔需要弯曲一点才能完全适合下一个呼叫站点,希望你没有破坏任何现有的(你看了看代码,变化似乎是安全的)。它是在每个其他svn up(不仅仅是我)之后运行测试,随后对有罪提交电子邮件的回复“你打破了它,请尽快修复!”最终使他们相信单元测试的至少部分效用。 无论你为讲座提出什么样的例子,他们都会告诉你它只有用,因为CUT与其他代码不切实际(或异常)隔离。他们会要求你为一个复杂的,错误的God Class编写单元测试(最好是单身人士,每个人都喜欢全局变量,不是吗?)因为,据他们所知,这就是现实代码的样子,他们认为TDD也会像这样。 螺丝讲座。让管理层为圣诞节买几本书:至少是TDD By Example(Beck)和Refactoring(Fowler)。从经验来看,这些书不一定会对他们中的大部分产生任何影响(更多的是“那不是真实世界”的废话),但它必然会坚持某人,而且,没有违法行为,我d赌1000美元贝克是你们两个最好的传道者。 ;)在您与他们分享的代码中练习TDD。如果确实有效,他们会跟随。 Sss-looowww-lyyyy,但他们会。 再说一遍,也许你的团队中没有那么多Willies,也许你的同事都很渴望,只需要一个领导者,我真的不知道,你没有说出来。 第一条诫命:不要因缓慢和/或部分摄入而被推迟:每一寸都很重要! (我在这里向自己讲道,你知道......)

xnam

赞同来自:

课堂风格的方法是否运作良好?这是一个我想到的问题,因为这里可能发生的事情是知识和应用这些想法之间的分离,尽管他们可能知道这些想法,但他们并没有完全掌握如何使用它。 只是为了给出一个不同的方法,人们可以跳进正在进行的任何项目,并开始尝试应用其中一些可能需要一段时间才能通过每个人流下来,因为想法是你要训练一个然后作为一对你会训练另一对,等等,试图让每个人都达到同一点。这样,不相关的理论内容就会被提前取出。 另一个想法是看看尝试在10人组中组建团队是否有意义,例如2组3组和4组或5组,这样每个人都可以展示他们已经做过的事情和表现如何他们使用这个吗? 我是第二次边界测试,并说明为什么用无效输入进行测试可以看到这不会导致系统翻转并死亡。 最后,有时间专门处理问题以及人们所拥有的其他1:1问题可能是有意义的,因为不是每个人都想在大集团面前提问。 编辑:第2课的注意事项,这是一个好主意,但有一些危害需要注意。首先,要谦虚地做这一课,这样你就不会成为一个想要抨击其他人的炫耀者。其次,我建议在讨论事情时保留一些不完整的测试,以便在这里有一个互动的方面,阻止其他开发人员只是调整或滚动他们的眼睛。第三,后续课程或其他两个人展示他们所做的事情,或者你对他们所做的事情进行了讨论,可能更有助于证明这是团队在某些方面的努力。

aad

赞同来自:

我认为从测试后的测试类型开始会更难。与test-first相比的一个主要区别是test-after不能指导您编写易于测试的代码。除非您第一次完成TDD,否则编写code for which it's easy to write tests将非常困难。 我建议从TDD / BDD开始,在掌握了它之后,继续学习如何在legacy code(也是PDF)上进行测试。 IMO,做好后测试比测试先做得更难。 为了学习TDD,我建议完成this tutorial。这应该让你开始编写什么样的测试。

dnulla

赞同来自:

让人们对其他人的/示例代码进行单元测试感兴趣不会像人们在他们必须编写的一些新代码上“从测试用例开始”那样有效。 涵盖从测试用例开始并三角测量到有效结果的基础知识(同时强调测试失败的进度)。 也就是说,我个人的经验是这样的事情在一对编程环境中做得更好。这对你来说是额外的工作,但是一对一,一些所有权和他们可以在最后引用的工作示例的组合将使采用变得更加容易。 在适当的环境下,在以后的某个时间点运行覆盖工具可以提供一种有趣,有竞争力和令人满意的标记进度的方法。以任何方式使这成为补偿/奖金的一部分是一个真正的坏主意。如果做得好,人们会采用它,因为它有效。

uvero

赞同来自:

我喜欢你在这里表达的承诺和彻底,但我的感觉是你的采用计划需要更长的时间,而不是直接开始,配对并编写一些实际的生产测试。无论如何,您还需要基础架构 - 为什么不使用CI服务器和TDD框架来引导您的实际生产代码? (很多时候,这比学习“断言”更难以解决。“尽快将这部分放在一边”。然后坐下来解决与编码员的实际问题。选择一个简单的错误或小功能,并尝试确定失败的测试会是什么样子并尝试编写它们。 我喜欢Hello Worlds的棕色包午餐或其他东西。但我想不出任何理由不直接进入并解决一些问题。

fet

赞同来自:

如果管理层对此非常认真,那么他们就必须采取措施并采取行动,而不仅仅是接受一点培训。开始让他们要求在代码审查中查看测试。一旦这很常见,并且人们知道他们不会在没有测试的情况下传递代码,那么让他们拒绝部署新代码,直到编写测试。在人们知道他们无法通过编写测试然后他们会相当可靠地完成测试之前,它只需要进行几次迭代。是的,经理第一次拒绝部署,可能会迟到。他们必须在自己的计划中采取这种方式。他们还需要开始在其任务估算中添加测试写入时间。没有人愿意这样做,如果他们认为他们会受到指责,因为编写测试和代码需要的时间比编写代码要长。有一个已发布的时间表来说明如何实现它(你需要给它们一些时间来学习如何在所有新开发需要它之前完成这个),并且在下降死亡日期,没有测试就没有任何东西可以生成。

cnisi

赞同来自:

仅仅因为我一直在做一些TDD(和一般的单元测试)非常宝贵并且因为它可能是一个很好的演示,我建议使用Regex的一个例子,特别是如果你不是一个正则表达式专家,它很容易犯错误。 这也是一个很好的'表演,而不是说'演示。如果你只是: 第1步:告诉他们只是用正则表达式编写一些代码以匹配某个模式。 第2步:将模式扩展为其他内容。 第3步:展示单元测试如何立即让他们确定a)它与新模式匹配并且b)它没有打破任何先前的匹配或通过不应该的结果。 在你的评论的一般C& C中,很难确切知道将发生什么序列事件。而且,如果在两者之间只有一个空洞而没有推动应用他们的知识,那么半月似乎太少了。你想要的最后一件事就是成为他们去的一个会议,一旦他们离开房间就会忘记! 您是否在当前工作负载中有足够的停机时间来解决技术债务并让团队实际配对并开始考虑将单元测试添加到某些现有功能并在必要时进行重构以允许进行模拟? 我认为这将比讲座和盆栽工作室YMMV更有效。

yet

赞同来自:

我帮助我的公司为Java开发人员设计和运行测试驱动开发培训。我们最终将其作为一整天的培训,我们将其分解为与您在此处的方式类似。

  1. 为什么要测试?
  2. 简单的例子。
  3. 更复杂的例子。
我必须强调的一点是,人们需要通过实践来学习。 对于我的培训,我们建立了一个实验室环境,每个学生都可以从相同的代码快照开始,自己开发和运行测试,教练在训练室里走来走去,帮助那些困惑或者没有得到它的人。 对于“简单示例”,我们在投影仪上有一个“烹饪节目”版本的代码,并逐步完成TDD流程。开发人员必须经历编写测试的过程,然后创建足以通过测试的实现,然后重复。在每个阶段,在学生有时间自己尝试之后,投影仪上会显示当前阶段的准备解决方案。 对于“复杂示例”,我们创建了一组要求,然后允许学生使用TDD来提出他们自己的解决方案。我们甚至进行了一项运动,需要惊喜,突然在练习中突然改变。 我喜欢你的想法,通过定期检查,在更长的时间内做这件事。我们培训的一个缺点是缺乏后续行动。开发人员受益于培训,我敢肯定,但我认为很多人并没有将这种做法带回到他们的日常工作中。定期检查有助于灌输单元测试作为习惯问题。 有关更多想法,请查看我对this question的回答。

yvitae

赞同来自:

我认为这是一个或两个会议的一个很好的大纲。但是我强烈建议首先建立一个测试基础设施,并让开发人员尽早获得成功,而不是将开发人员先推进单元测试世界,然后大喊“准备好,设置好,开始!” 假设您在IDE中进行开发,一键式测试生成器工具将真正有助于第一步,即测试创建。您需要将基于GUI的测试运行器与IDE集成,并且您确实需要一个与CI构建集成的自动测试运行器。将代码覆盖工具与测试运行器工具集成在一起将有助于开发人员扩大其覆盖范围。您需要为开发人员提供编写测试的完整框架,其中包括记录如何组织测试源代码(测试命名标准,项目设置,文件夹位置等)。自动执行任何手动步骤的工具将变为很长的路要走。为您依赖的任何内部或第三方库API提供包含模拟对象的模拟框架。如果你要推荐一个装满假数据的数据库(而不是一套假的数据访问对象),用一些关键表创建一个并用测试数据填充它,并提供在测试运行之间重置它所需的一切。如果没有,请提供一些您自己的假DAO作为示例。您应该在源代码管理系统中测试生产代码中有一小组测试,以显示示例。而且您需要记录所有这些内容,以便在会议#1中将其交付。 (别忘了测试文档!) 我们的一个团队在几年前尝试了临时方法,但采用率很低。没有测试的定义或组织,个别开发人员就会做出自己的事情。缺乏命名标准使得难以确定运行哪些模块的正确测试,并且很少有人打扰。我们没有任何IDE集成。没有人想写嘲笑,我们没有提前为我们使用的框架提供模拟。并且很难将测试添加到未使用依赖注入编写的遗留代码中。 我现在正试图重新组织我们的基础设施,并准备好再次完成任务。只有在它站起来之后,我才会努力让开发人员再次使用它。 但是,你有一件我们上次缺乏的东西,这是强有力的管理支持。我们以前的经理对这个想法不太热心,因为他们不想通过编写所有这些测试来延迟编码。我们现在有了新的管理,他们专注于代码质量 - 自动化单元测试现在流行,所以现在是我们再次尝试的好时机。

cut

赞同来自:

我喜欢。我有一个评论是,它可能值得放弃一些关于如何测试线程/异步代码的指导/建议。 另外,我会对边界测试发表评论,即使用单元测试来陈述您对所使用的任何第三方API的假设。