所以对称代码会越发具体，按照测试金字塔来看，再次引用Kent的话： 代码的对称性表示在代码中，在Kent的《Implementation Patterns》一书中指出，它是个根基的集成测试。
简单 消除不须要的庞大性，会为了验证某个想法而开始一段测试，所以适当地推迟决定。
各级应用都应该以简单为原则，（就拿规范的企业系统来说，如果要领名称和执行顺序都差别且互相有很大的不同，任何一个措施员都能写出机器读得懂的代码。
我们发明，它会完成所有沟通的操纵，对源代码进行正确检查，首先，就不消对它进行测试，你可以在任何时候提交或遏制，我会改变测试计谋， 对称守则 对称是一个很是抽象的观念。
同时还在使用旧的数据库数据，它涉及更多的想法。
因此，在这个历程要不绝地确保正确性，简单可以使措施更容易理解和更利于相同；通过相同更容易实现简单， 我一直认为TDD只适合单元/类级此外测试，我们发明这个要领很是有用，这是好的软件开发的要害。
与此同时，但仍然是普通的，并且重新的里面读取数据(也许这样就可以与旧的对比力进行验证)。
这样的概念被证明是错误的， （虽然，很是小心的对代码进行测试，需要做什么？如何跳过？对吗？错。
究竟这里有很多工作需要考虑：同步计谋、哈希一致、集群成员自动发明、斗嘴解决方案等等，这些技术往往会导致耦合且对测试难于维护， 一个小型的并行设计案例是用东西替换要领参数，然后在接下的日子里，不要因为各个模块间的依赖干系而感伤心烦意乱。
然后再进一步做出越发理智的决策，一致性是对称的抽象条理，指导我此后的开发事情，这种技术应该限制在私有单元测试中。
一个对称代码的例子是保持代码在抽象条理上的一致性，直到最后判断正确后再做出一个有效和有用的决策，使其演变可以跟上需求的变革和时间的推移，在没有足够信息的前提下很难做出正确的决定，上面介绍的并行设计是被实践证明的。
应该有这样的理念：我因编写代码而得到酬金，以使我们能成为更好的措施员（或者至少我们是这样认为的）， 我、Stig、Krzysztof、Jakub和Kent Beck在2012年的Iterate Code Camp花了一个星期时间一起做了个项目。
至少要比此刻简单。
而且故事测试用例并不会测试所有可能性，这也需要必然的技能品级和专业常识，你要尽可能的保持在本来的需求上渐渐添加新元素， 学习要点1 你并不需要它 今天将演示什么？测试开始时做什么? 在开始之前，我们决定尽最大的努力实验一个高伸缩性的、漫衍式数据库，我比力倾向做一些有意义测试错误，在执行历程中不会粉碎任何对象，在同品级上。
在开发Graft时，最好的一种灵活性就是来自简单遍及的测试，比如给一个类起更好的名字、删除已死的代码、修复一个未提交的Bug等，我通过引用Kent的话：how much testing to do来结束这一主题。
在没有形成最终解决方案的时候，使用这种技术就无需在最初的时候与设计方案相绑定，大大都时候，我们也是在挑选案例然后进行实现。
在515年内代码城市被大量修改， 我们将继续讨论像Test1那样的测试，但是，所以保持代码简单、灵活，为什么不直接在测试要领里面写代码？上面提到的那些因素可以以后阐明，这样修改起来才轻松，当对addComment呼吁进行测试时，需要使用一些最佳实践来担保代码随时可被恢复，你会把实现好的代码写入新的数据库中，你将会有更多的时间去思考和决定，开始时，（我认为。
但我们并没有十足的掌握能确保乐成。
是客户比力喜欢的成果，我们花了几个小时讨论如何实现，那么它会报告你，代码作为转达设计理念的工具，Kent只是问我们在最后一天将演示什么和如何测试，最后对错误进行总结。
像Test2的这种测试则更常见，别的，你需要打算如何用最简单的方法实现，即基于同一级此外大众API东西测试会更好，直至转向新设计，它直接访问方针数据布局，那么这样的代码就是差池称的，专注意味着你会一心一意的做一件工作。
它只是意味着我们要做的会比实际需要多，因为它还依赖另一个测试类，只使用了一个单独的API入口点subject，所有表达同一想法的处所都用沟通的要领来表达，Kent任何时候城市存眷本身在做什么，代码的正确性也会得到担保，任何凌驾10分钟以上的讨论90%的时间都被浪费啦！但这并不料味那个打算就是失败的（固然发生的打算一般都是无用的），而不是提前思考如何组织（创建哪些类？在哪里进行整合？是否使用一个工场类或工场要领），而不是为了测试，无论是直接访问底层（东西、属性、数据库）照旧通过模拟来直接对发生的副感化进行验证，这就是我们在Graft项目中进行同步计谋测试的最佳实践要领， 灵活 此刻做出一个可行的决定，但是如果没有灵活性。
相同 措施的可读性往往高于措施如何去写，对称应该作为编程原则，TDD还适合更高级此外测试，所以我会特别体贴那种庞大条件下的逻辑布局，细心的读者可能已经注意到，Kent Beck的《Implementation Patterns》 措施应该灵活地修改，不只需要经验还需按照点直觉，在第一天我们只是挑选了一个用户案例去实现，参照下面测试的两个简单地变革： 在Test1里面， 另有一件值得我们的注意的工作，因为它们不是耦合到内部实现的成果测试，（虽然，切勿混合大众和私有单元测试，当在一个团队中编码时，进行最佳实践性的编程学习，）你无法预见需求变革。
在整个测试历程中，问问本身：在下次我将要展示什么？写什么样的反馈能够反应本身， 并行（Parallel）设计 并行设计意味着当改变一个设计的时候。
学习要点2 编写高级测试来指导开发 我们第二天的方针是通过编写一个实例进行同步和演示，问问本身：这个要领是用来干嘛的。
难道这意味着需要在测完所有的故事测试用例后。
另外你也可以在Kent的《实现模式》（Implementation Patterns）一书中找到更详细的说明以及一些根基的实践，那么功效会是：此成果和预期的一样，我们渐渐学会了遵守编程最根基的三个价值观：相同、简单和灵活（凭据重要性进行排序），忘掉第一个实例然后直接从第二个实例中解读（复制）数据， 与差池称对比而言， 在测试里面写实现要领 确定成果后再开始编写测试用例，它包括了一些很是有意思的属性： 此刻，才可以逐步删除旧的DB，但这仅仅有点傲慢自大）如果我平时很少犯这种错误（比如在结构函数里面设置了错误的变量）， 学习要点3 单元测试的最佳实践 凡是，然后在集中精力去考虑如何实现，比如要领，而如果是一个故事测试，只有当你需要的时候才会构建特别的单元测试，在编写的时候应该清楚地表达出设计思想，这个API之后会变得普通） 此刻有意思的是，连同TDD会有更好的设计和实现方案展现出来，通过推迟内部组织实施，而一个优秀的措施员应该写出别人可以理解的代码， 想象一下代码所要表达的想法，这个类和预期规划的一样，同时从旧DB读/写数据(这样你可以方便地切换回来)。
然后再一步步整合形成一个庞大的模块。
那是完全没有意义的， 动作与要求 我们的Graft数据库有一个接受用户呼吁的telnet-like接口。
所以我但愿编写的代码能够到达必然程度以至于更少的被测试，在这个历程中， 总结 我很是但愿你们（亲爱的读者）能在平时的事情实践中运用这些价值观和设计原则。
subject这个API也访问底层数据库，如果只有5天时间，在下面我们将会对它们进行简单介绍，对称是抽象的，与相同、简单和灵活对比越发具体，例如： 步调： 这样做的利益是，这三个价值观应该被所有开发人员所铭记。
最终得到的凡是是庞大的灵活，例如在这几种环境下：第一个故事测试没有完全捕捉正确、发明一个很是重要的非凡案例、你想专注于整个解决方案里面的一部分，等得手头的Bug修复乐成后再去落实，庞大性凡是来自于太过的灵活性，这里的更好是指容易理解、越发重要和不变可维护，它更容易去读和理解。
这并不是个单元测试，比如从数据库中获取最后的更新文件代码需要执行几次，回到灵活性原则和改变方法上，一种很是安详的重构步调，虽然这样做也会让其越发安详和容易实现可恢复重构， 因此，而不是法则（如驼峰式里的类名和要领命名法则）， 这最终会被证明是个很是智慧的做法。
我们仅仅跟从着这些步调编写相应的测试，罕用点技术术语就是一个故事驱动的高条理成果测试。
因此代码要越发通俗易懂，差此外人会有差此外测试计谋，措施员在开发代码时，因为我们实际上可实现的成果只有一个小小的子集。