sm羞耻任务_羞耻驱动的发展

我们有许多使用Easy Mock编写的古老的单元测试; 我们所有最近的单元测试都使用JMock 。 这笔小小的技术债务意味着，如果您要更改仅适用于Easy Mock测试的代码，则首先必须决定：您要修复测试，还是可以hold着鼻子去适应现有的测试，或对其进行调整？你的目的？ 这不仅使人分心，而且意味着做正确的事情可能会慢得多。
原则上，将Easy Mock测试更改为JMock是一项相对简单的任务。 Easy Mock通过一种简单的方式声明模拟：

private PricesService prices = createMock(PricesService.class);

这些可以轻松转换为JMock样式：

private Mockery context = new Mockery();
...
private final PricesService prices = context.mock(PricesService.class);

EasyMock声明期望的方式略有不同：

prices.prefetchFor(asset);
expect(prices.for(asset)).andReturn(
    Lists.newListOf("1.45", "34.74"));

这些需要转化为JMock的期望：

context.checking(new Expectations() {
    
    {
    allowing(prices).prefetchFor(asset);
    allowing(prices).for(asset);
        will(returnValue(Lists.newListOf("1.45", "34.74")));
}});

这个过程是非常机械的，因此，在10％的时间里，我开始使用脚本化的重构工具Rescripter将我们的EasyMock测试机械地转换为JMock。 Rescripter让您运行修改Java源代码的代码。 但这不只是简单的搜索和替换或正则表达式：通过使用Eclipse强大的语法树解析，您可以访问源文件的完全解析表示形式–这意味着您可以找到对方法的引用，查找方法调用，名称，参数列表等。鉴于从一个库到另一个库的翻译性质，这正是您所需要的。

这不可避免地是相当探索性的编码 。 我不确定是什么可能，翻译过程最终会变得多么复杂。 但是我从上面的一些简单示例开始。 但是，随着时间的流逝，由于库之间的许多差异使得我越来越难以完成翻译工作，因此复杂性也在增加。

经过10％的工作，我设法整理了一些很棒的东西：我翻译了几百个单元测试； 但是，这是由700行您曾经遇到过的最怪诞的代码完成的！
然后……然后上周，我得到了当天的一对伴侣。 他不得不分享这个恐怖。 用了10分钟的时间向他解释了问题，然后又用了15分钟的解释原因，这是一次性使用的代码，因此没有任何单元测试。 我很不好意思。
我们开始尝试进行一些小的更改； 但是如果没有测试框架，很难确定我们正在做的事情是否可行。 更糟的是，我们需要更改许多地方使用的核心功能。 这让我感到紧张，因为没有测试覆盖面-因此我们无法确定我们不会破坏已经存在的内容。 坦白说，这绝对是一场噩梦。 我已经习惯了进行测试覆盖并编写测试-在没有单元测试的情况下编写代码的想法使我无所适从。 但是，这里是我自己创建的一堆未经测试的代码。 为什么？ 因为我原谅自己没有“做对了”。 毕竟，这只是一次性代码，不是吗？ 这是探索性的，比生产代码更重要。 无论如何，一旦完成并迁移了测试，此代码将无用-那么为什么要使其漂亮呢？ 我只是继续偷走…… 听起来多么合理，真是令人惊讶。 直到您意识到自己是个彻头彻尾的笨蛋。 即使是一次性代码，即使保质期相对较短

快速前进的唯一途径就是前进

所以我做了任何有理性的人都会做的事情。 我花了我的午餐时间来修复这种状况。 最终结果？ 现在，我可以在Jasmine中编写单元测试，以验证我正在编写的重构。
现在，我不仅可以正确地测试驱动新代码。 我可以编写测试以涵盖现有的旧版代码，因此可以适当地对其进行重构。 惊人。 突然之间，进步的步伐跳了起来。 我没有一个漫长的调试周期，而是尝试手动查找和触发测试方案，而是有了一个易于运行，可重复的自动化测试套件，这使我对自己的工作充满信心。

这对我来说都不是新鲜事物：这是我日复一日地做的事情。 但是……但是…………我以某种方式原谅自己独自编码。 我能得出的唯一结论是，我们不能单靠编写任何价值的代码就值得信赖。 让另一个人看到您抱歉的代码借口的可耻之处是，配对时提高了质量： 如果您不配对编程，那么您编写的代码就必须是可耻的 。

参考： Actively Lazy博客上的JCG合作伙伴 David Green的羞耻驱动开发 。