在单元测试的10分钟Grok演讲中,你会包括什么

单元测试就是关于 信心

它允许您确信您的代码是可靠的,并且其他人在编写自己的系统部分时可以依赖它。如果您能够理解单元测试将有助于消除新系统第一次发布时带来的恐惧,我希望您的听众很快会非常感兴趣。

单元测试->重构->生活守则。

编辑: 顺便说一句,我不会引用MichaelFeathers的话“所有没有单元测试的代码都是遗留代码”。当我第一次听到它时,它确实让我感到防御性。当人们不再感到被冒犯的时候,这10分钟就结束了:-)(我个人认为这句话是真实的,而不是有用的)。

下面是一个关于技巧X的简短演讲的好格式:

• 您个人从使用X获得了什么

“出售”或在理论上花费大量时间。 事先做好准备,并向人们指出需要阅读的书籍、文章的URL或教程 你

试着简单地谈谈测试驱动开发的方面:首先编写测试和接口,然后实现一切。

也可能是关于持续集成,这意味着一旦你在你的源代码管理系统中检查了一些东西,项目就会被编译,所有的测试都会运行,这样开发者就可以立即知道他是否做错了什么。

您可以提到,这将是一个艰难的学习曲线,它会让人感觉生产率正在受到影响,但好处是值得的:

实现一个类(如果您愿意,可以使用TDD),并展示单元测试如何捕获破坏该类的修改。

此外,如果您单独测试组件(即,您不需要启动web应用程序、登录、转到功能、测试),您可以强调如何更快地开发组件;您可以运行测试。

您可能能够在您公司的一段代码上执行此操作,并可能展示单元测试如何捕获您最近遇到的bug。

如果您进行了演示,请在每个人都熟悉的项目中的一段工作代码上进行演示。避免做作的例子。关于TDD的书已经有很多了,但它们并没有真正宣传TDD是如何为一个真正的项目工作的。

我要证明:

• 它为您生成的代码提供了信心
• 代码覆盖的好处,不再是“哦,那else语句从未被测试过!”

FWIW我们在Hudson box上通过MSTEST运行糟糕的visual studio测试,我有一个xslt,Hudson使用它将结果转换为nunit格式,以便Hudson能够破译它们。如果他们想让你坚持使用微软的测试平台,那就把它放在那里。

责任 IT Conversations . (他关于问责制的观点始于30:34。)

从业务的角度来看,您可能希望强调一个事实,即单元测试可以“降低”您对代码所做的任何更改的风险。一旦有了一套单元测试,就可以对代码库进行更改,并知道哪些中断了,哪些没有。

进行用户测试可能不是个坏主意。如果您有一组好的测试,您可以在进行更改后将失败的测试带给用户,让他们验证新结果是否正确。此外,如果让用户为您编写新的单元测试定义,您可以简化需求收集。他们不需要能够编码,但他们确实需要能够为您提供适当的输入和预期的输出(否则他们如何知道他们要求的更改是否有效?)。

VisualStudio有一套非常好的单元测试工具,因此一两个示例可能会让您的团队了解单元测试在实践中是什么样的。

穿 this t-shirt

精心准备的现场演示:

1. 在“应用程序”中查找“bug”
2. 编写一个单元测试来覆盖这个bug。
4. 显示,您的代码是绿色的。

所以你可以证明,那是不可能的 这 错误将再次出现!

提出一个可以通过创建算法来解决的问题。当然是相对简单的事情。接下来,在DLL项目中编写此算法。尝试隐藏一些弱点(i<=数组。长度总是一个好的)。接下来,询问他们如何测试这个DLL。

大多数开发人员运行应用程序来测试它们。但是你不能运行DLL。您可能会得到一些建议,建议您创建一个控制台应用程序来创建执行该算法的方法。向他们展示您如何设计单元测试来实现这一点。

• kent beck关于单元测试的论文
• 链接到使用所选测试框架的任何较大样本