|
|
1
3
真正的动力来自内心。有些人会抓住每一个机会来玩弄这个系统,有时他们没有别的理由。其他人这么做只是因为他们是黑客。 这就是说,假设你是经理,和开发人员开一个“来见耶稣”的会议。如果这仍然不起作用,那门总是开着的。 如果你不是经理,那就通过适当的渠道进行沟通。 |
|
|
2
1
开发人员是TDD的新手吗?也许他们需要一些关于编写好的测试等的指导。否则,他们需要踢屁股,并向他们强调测试似乎并不比他/她正在生成的代码更重要。 哦,是的,关于插件的事情,忘了这一点,你正在做的相同的代码检查应该足够好了。 |
|
|
3
0
您应该指定您正在使用的语言/框架。
在最简单的情况下,我想应该很容易发现
|
|
|
4
0
任何通过的测试都是可疑的吗? |
|
|
5
0
您必须使用的一段错误代码将是一个很好的起点--您必须确保它能正常工作。。。 |
|
|
6
0
|
|
|
7
0
由两个或两个以上已经受测试影响的开发人员进行的代码审查,可能是让有问题的开发人员看到自动化单元测试真的没有那么困难,也没有那么不寻常的最好方法。在每次审查中有两个受测试影响的开发人员将加强质量单元测试对他来说的重要性。 mutation testing Nester ,(相当于 Jester )是一个你可能会发现有用的工具。
"Why do most developers not write unit tests, still?" 我觉得在这里读书也不错。 |
|
|
8
0
我想你应该先让他写一个不及格的测试。试着让他养成那种习惯。单元测试新手ppl通常很难编写单元测试。 还有一些工具可以帮助您“探索所有可能的代码路径”。我建议你看看, 皮克斯 让您的开发人员结对程序,当您与其他人在同一个函数上工作时,“懒惰”要困难得多,这将分散代码所有权。你似乎没有这么做,因为你说“ 他的 此外,单元测试并不是消除所有问题的圣杯。。。它们应该是你可以使用的工具之一。
|