本节书摘来自华章出版社《有效的单元测试》一书中的第2章，第2.2节，作者 （芬）Lasse Koskela，更多章节内容可以访问云栖社区“华章计算机”公众号查看
2.2 结构有助于理解事物
我看过无数的代码库，痛并快乐着，天才的美妙步伐并没有在那些源文件中徜徉。某些文件从未跳转到另外的源文件，因为它的全部内容都在一起——所有代码和逻辑，比如，Web表单的提交全部都放在一个源文件里面。我曾经愚蠢地试图打开一个超大的源文件而导致文本编辑器崩溃。我还见过一个Web应用程序报错，是由于JSP文件膨胀得太大，导致生成的字节码违反了Java类文件的规范。不仅仅说结构是有用的——缺乏结构更是有害的。
对于这些又臭又长的源代码，基本上没人愿意碰它们。即使最简单的概念变化都难以映射到你面前的源代码上。没有结构可以让你的大脑依靠。无法分而治之——你不得不在脑海里处理整件事情，或者准备好用脑袋撞墙。
如图2.1所示，你不是想随便要一个结构来帮助理解。你需要这样的结构——用与你的大脑和心智相匹配的方式来分解事物。盲目地将代码外化为单独的源文件、类或方法，在一定时间内能减少代码的数量，从而降低大脑的负担。但是那并不足以隔离和理解我们感兴趣的程序逻辑。于是你需要一个有意义的结构。
当面对庞然大物，即没完没了的源代码清单时，一个明显的解决方案是将它们切成碎片，将代码块抽取到方法中。可以将一个包含500行代码的巨型类分解为10个类中的几十个方法，将方法的平均长度降低到10行以下。那会向代码中引入更多结构——至少编译器这么认为。这样你也能够在屏幕上看见整个方法，而不用上下滚动。
但是如果分解庞然大物的边界不甚合理——如果它们没能映射到领域和抽象上——我们可能会适得其反，因为现在各个概念之间在物理上可能比之前更加分散，反而增加了你在源文件之间来回切换的时间。很简单。重要的是代码结构是否有助于你快速而可靠地找到高层概念的代码实现所在。
对于这种现象，以测试代码为例是极好的。假设你的应用程序被自动化测试相当好地覆盖着——但就一个自动化测试。想象一下，这个测试只有一个巨大的测试方法，花了半小时执行应用程序的所有逻辑和行为。假设因为你在程序内部对邮件地址的显示方式做了一点调整，但是却把一些东西搞乱了，因此测试最后失败了，如图2.2所示。这是个bug。接下来会怎样？
我能想象这要花一段时间才能在测试代码中找到确切的出错位置。测试代码缺乏结构，无助于你理清相互的影响、某个对象是在哪里初始化的、出错时某个变量的值是多少，等等。最终，当你设法找到和修正了错误，你只得再次运行整个测试——整整30分钟——来确保你真的修复了问题，并且在这个过程中没有再破坏其他东西。
继续这个思考实验，设想快速地倒退到一个小时前，此时你正要改动另一处。这次你学乖了，你要小心地确保自己理解了当前的实现，保证自己做了正确的改动。那你会怎么做？去阅读代码，特别是精读测试代码，它会具体地告诉你生产代码的预期行为。只是你找不到测试代码的相应部分，因为它缺乏结构。
你需要的是专注的测试，它可读、可达、可理解，这样你才能：
找到与手上任务相关的测试类
从那些类中识别出合适的测试方法
理解测试方法中对象的生命周期
关注测试的结构并确保它有用，你就可以做到这几点。当然，具备有用的结构还不够。
