966,690 七月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
Android中的单元测试
Android中的单元测试
日. 估计阅读时间:
智能化运维、Serverless、DevOps......2017年有哪些最新运维技术趋势？!
相关厂商内容
相关赞助商
CNUTCon全球运维技术大会，9月10日-9月11日，上海&光大会展中心大酒店，
之所以这些框架的测试用例都需要在模拟器中运行，是因为我们平时在开发时所使用的Andorid.jar是被精简过的，只是用于日常开发的，它只是一个placeholder，使得我们在开发时能够不出编译错误，它完全是一个stub包，其中所有的类都只是Android平台接口的一个stub，如果在代码中运行这个Android.jar，它们所有的方法都只会抛出一个java.lang.RuntimeException(&Stub!&)异常。所以，一旦测试代码需要真正调用Android平台相关的类或接口，它们就必须运行于真正实现了Android的环境，如模拟器或者是测试机器。
我们的另外一个选择是只对POJO进行单元测试，如果遇到Android相关的代码，就使用Mock框架对其进行模拟。这种方式一定程度上可以解决我们的问题，但这意味着我们需要大量的在测试环境中使用mock和stub。另外，虽然Android中界面的布局通常使用XML来实现，但项目的代码中还是会存在各种对界面的操作和更新，UI和逻辑的耦合使测试更加不易。
而且即使这样，由于Android平台的复杂性（static方法，final方法和类，Context和Resources的管理），我们也很难对Android相关的代码进行测试，以保证测试率。
那么如何能够在不增加开发成本的情况下，有一个稳定快速的单元测试环境呢？
我们目前的选择是使用MVP模式和Robolectric
Android的体系结构非常适合于使用进行开发，与不同，Android中的Activity并不是一个标准的Controller，它的首要职责是加载应用的布局和初始化用户界面，并接受并处理来自用户的操作请求，进而作出响应。随着界面及其逻辑的复杂度不断提升，Activity类的职责不断增加，以致变得庞大臃肿。当我们将其中复杂的逻辑处理移至另外的一个类（Presneter）中时，Activity其实就是MVP模式中View，它负责UI元素的初始化，建立UI元素与Presenter的关联（Listener之类），同时自己也会处理一些简单的逻辑（复杂的逻辑交由Presenter处理）。如图所示：
通过这种职责的分离，一方面代码的可读性得到了提高，另一方面我们可以更为方便地通过mock Activity的方式对各种逻辑（Presenter中的方法）进行测试。
对于测试环境的搭建和测试Android相关的代码，我们则借助于的帮助。
Robolectric在其所提供的测试框架中，完全模拟了Android SDK的jar文件（不会再有恼人的stub异常），它使得我们的测试可以运行于JVM之上（速度得到大幅度的提升），因此我们可以用它对Android应用进行测试驱动开发。Roblectric同时实现了Android中对XML的解析，模拟了View，Layout，以及资源的加载，它使得Android的环境对于开发人员来说更像是一个黑盒，从而使开发人员不用大量使用mock，就可以方便的对资源状态和Android相关的代码进行测试。
Robolectric是如何做到这点的呢？
Robolectric使用了在运行时动态修改Android.jar中类的byte code，Robolectric会在JVM加载Android.jar包的时候，重写其中类的方法。Roblectroic会让这些方法有返回值（null或是0） 而不是抛出异常 ，或者将这些方法调用转向来模拟Android SDK的实现。Shadow Objects是Robolectric在运行时插入到Android.jar包相应的类中的，它们会实际处理方法的调用，并记录相应的状态，以备在assert的时候进行查询。如图所示。Robolectric提供了大量的Shadow Objects，覆盖了测试开发过程中绝大多数逻辑功能的需要 。
Robolectric的使用
基于Robolectric的测试需要使用其特定的test runner（RobolectricTestRunner）来运行，我们可以通过扩展RobolectricTestRunner来创建一个自己的test runner，并在其构造函数中设定需要加载的AndroidManifest.xml和resource目录 。如：
public class MyTestRunner extends RobolectricTestRunner {
public MyTestRunner(Class&?& testClass) throws InitializationError {
super(testClass, new RobolectricConfig(new File(&my_app/AndroidManifest.xml&), new File(&my_app/res&)));
有了自己的test runner, 我们可以来写一个简单的Robolectric测试了
1 @RunWith(MyTestRunner.class)
public class SignInScreenTest {
public void should_start_intent_when_click_registration_button() {
Activity activity = new Activity();
SignInScreen signInScreen = new SignInSceen(activity);
TextView textView = (TextView)
signInScreen.findViewById(R.id.sign_in_registration);
textView.performClick();
ShadowActivity shadowActivity = Robolectric.shadowOf(activity);
Intent nextStartedActivity = shadowActivity.getNextStartedActivity();
ShadowIntent shadowIntent = Robolectric.shadowOf(nextStartedActivity);
assertThat((Class&WebPageActivity&) shadowIntent.getIntentClass(), equalTo(WebPageActivity.class));
在这段测试代码中：
（1）声明了测试运行的test runner；就像普通的单元测试，它也分为了set up， method invoke，以及assert三个阶段。
在（2）中，测试初始化了一个Activity用于提供Context，并使用这个Activity对象生成了一个SignInScreen实例；
第二个阶段，也是就（3）中，代码在生成的登录界面中找到注册按钮，并进行点击。最为有意思的第三个阶段需要验证注册按钮的点击触发了我们期望的事件，即使用Implicit Intent来打开WebPageActivity。
为了进行这个验证，（4）中首先通过Robolectric的静态方法shadowOf来获取activity对象相应的Shadow Object ，而通过这个Shadow Object,代码获得了activity对象的所开启的Intent对象。最后通过Intent对象的Shadow Object ，我们可以获得其intent class并进行验证。
通过这个测试我们可以看到，有了Robolectric的帮助，我们可以轻松的生成Activity实例，加载xml布局文件，进行组件上的方法调用。通过shadow对象，我们则可以获取Android相关类的对象状态信息，来对测试的结果进行验证。实际上除了Intent，我们还可以对通过使用Robolectric对代码中的Dialog，HTTP请求，数据库操作等各个方面进行测试。
Robolectric并没有为Android SDK中的所有类都定义shadow对象，你可以通过调用 Robolectric.getDefaultShadowClasses() 方法来查看你所需要的类是否已经被注册到了需要被shadow的类列表中。如果没有你可能就需要对其进行定制和扩展。关于如何添加Shadow Objects而增加Robolectric的功能，在Robolectric的中有详细的描述。
由于Robolectric的测试是可以脱离Android的SDK运行于JVM上，我们就可以像运行普通的jUnit测试一样在IDE中或者在终端使用构建脚本运行我们的测试。
由于Robolectric的更新并不是很频繁，我们在平时也遇到了一些需要定制的情况，如支持Android4.0，使用sonar进行项目质量分析等等。所以我们在github上fork了Robolectric的工程，并以git submodule的方式将其加入到我们的工程管理中来，这样，我们就可以根据自己的需要来对Robolectric进行修改和扩展。由于我们对Robolectric的修改频率非常的低，在每一次修改后，可以将其编译打包成一个jar文件，将这个jar文件加入到我们的工程管理中，让我们的测试代码仍然依赖于这个jar文件，这样可以免去在运行测试中不必要的对Robolectric的重复编译，加快测试代码的运行速度。
我们在当前的项目中也进行了一定的关于验收测试方面的尝试，由于测试脚本是开发人员与BA以及QA进行沟通的一种重要途径，也是开发人员和QA进行人工测试的基准，因此我们仍然选用了cucumber作为我们编写脚本的工具，再使用cuke4duke和jRuby对其进行解析和执行。但目前这种测试方式似乎并不成熟，我们在这种尝试和实践的过程中遇到了种种的问题，主要在于测试编写和维护上的困难，这也导致了我们验收测试的覆盖率并不高。我们也会在这一方向上进行更多的尝试，如果大家有更好的关于验收测试自动化方面的实践，也希望能够得到你们的帮助和指正。
张磊，ThoughtWorks程序员，在J2EE, RoR, Android和iOS平台有开发经验，喜欢漂亮的代码和解决方案
感谢对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至。也欢迎大家通过新浪微博（）或者腾讯微博（）关注我们，并与我们的编辑和其他读者朋友交流。
Author Contacted
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
Presneter是presenter？
Re: 关于fork
SignInScreen是Activity还是presenter？
感觉这个可以被Epresso替代
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
InfoQ每周精要
订阅InfoQ每周精要，加入拥有25万多名资深开发者的庞大技术社区。
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
找回密码....
InfoQ账号使用的E-mail
关注你最喜爱的话题和作者
快速浏览网站内你所感兴趣话题的精选内容。
内容自由定制
选择想要阅读的主题和喜爱的作者定制自己的新闻源。
设置通知机制以获取内容更新对您而言是否重要
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。Android单元测试（二）：再来谈谈为什么 - 简书
Android单元测试（二）：再来谈谈为什么
今天早上8点半坐到桌子前，打开电脑，看了几分钟体育新闻，做其他一些准备工作，到9点开始真正开始着手写这篇文章。于是开始google，找资料，打算列一大段冠冕堂皇的理由，来说明为什么要写单元测试，比如：
对软件质量的提升
提升代码设计
等等等等。然而我发现上面提到的几点，都不是很好解释。首先，我并没有具体的数据，来说明有了单元测试，我们的app crash率降了多少，bug少了多少等等。这种东西首先我们没有去衡量，因为单元测试的增加是循序渐进的，每个版本的迭代增加一点点。很难，我们也没有，去前后对比。再次，crash率的降低和bug的减少，也难以证明就是单元测试的作用。另外，像重构这种理由，怎么举例证明呢？例子小了显得没有意义，例子大了写起来很困难，读起来也困难。而关于节约时间，我也没有测量过，这个恐怕也很难去测量。只能从理论上去说明，为什么可以节约时间，恐怕也很难有说服力的去论述。同样的，对于代码设计的提升，也很难有力的去证明。更重要的原因是，上面提到的种种好处，好像其实并不是我之所以要写单元测试的直接原因，更多的，他们像是一种结果。所以如果从列举和证明单元测试的好处这个角度去说明为什么要写单元测试的话，我感觉甚至很难说服我自己。那就从自身的经历和感受去说说，我为什么要写单元测试吧。其实我之所以要写单元测试，或者说这么喜欢单元测试这种写代码的方式，是出于我自身的原因，或者说因为自身的一些缺点，让我走上了单元测试这条路，而且再也不想回头。
我为什么写单元测试
首先，是因为我不够自信
我相信大家都有接手，或者说参与到一个新项目的经历，也许是因为换了工作，也许是因为职位调动，或其他原因。当我拿到一个新项目的时候，会有一种诚惶诚恐的感觉，因为一时间比较难理清楚整个app的结构是怎么划分的，各部分各模块之间又是什么样的关系。我怕我改了某一个地方，结果其他一个莫名其妙的地方的受到了影响，然后导致了一个bug。这对于用户群大的app，尤其严重。所以，那种时候就会希望，如果我改了某个地方，能有个东西告诉我，这个改动影响到哪些地方，这样改是不是有问题的，会不会导致bug。虽然我可以把app启动起来，看看是不是能正常工作，然而一种case能工作，并不代表所有影响到的case都能工作。尤其是在不知道有哪些地方用到了的情况下，我更加难以去遍历所有用到的地方，一个一个去验证这个改动有没有问题。哪怕我知道所有的case，这也是一个很痛苦很费时间的过程，而且很多的外部条件也很难满足，比如说需要什么样的网络条件，需要用户是会员等等。在这种情况下，单元测试是才是最好的工具。首先，单元测试只是针对一个代码单元写的测试，保证一个代码单元的正确性总比保证整个app的正确性容易吧？遍历一个方法的所有参数和输出情况总比遍历一个app的所有用户场景容易吧？跑一次单元测试总比运行一次app快吧？因此，在改现有的代码之前，我会先对要改的代码单元做好隔离，写好测试，再去改，改好以后跑一边单元测试，验证他们依然是通过的，这时候我才有信心，将代码合并进去。同样的情况会发生在重构的时候，我是一个对烂代码不大有忍受能力的人，看到不好的代码，我会忍不住想要去重构，不然的话，没有办法写新的代码。而重构就会有风险。因为我不够自信，重构的时候，也会有一种诚惶诚恐的感觉。这时候如果有完备的单元测试的话，我就能知道我的这次重构到底破坏了哪些地方，是不是对的，这样相对来说，就会放心的多了。因此，想用单元测试来保证代码的正确性，这个是我喜欢写单元测试的重要原因之一。
再次，是因为我没有耐心
对于有一定经验，有一定代码思想的人来说，当他拿到一个新的需求，他会先想想代码的结构，应该有那些类，那些组件，什么责任应该划分到哪里去，然后才开始动手写代码，这个是很自然的一个思维过程。然而在不写单元测试的情况下，我们可能要把整个feature都做完整，从model到controller(或Presenter、ViewModel）到view到util等等，一整套流程做下来，到最后才可能运行起来看看是不是对的，有的时候哪怕所有代码都写完了，也不一定能验证是不是对的，比如说后台还没有ready等等。总之，在没有单元测试的情况下，我们需要等到最后一刻才能手动验证代码是不是对的，然后发现原来这里错了一点，那里少了一点，然后一遍一遍的把app运行起来，改一点运行一遍。。。当我开始写单元测试之后，我发现这个过程实在是太漫长了，我喜欢写完一部分功能独立的代码，就能立刻看到他们是不是正确的。如果不是的话，我可以立刻就改正，而不用等到所有代码都写完整。要达到这点，那就只有写单元测试了。当然，哪怕有单元测试，最后还是要做一遍手动测试工作，然而因为前面我已经保证每一个单元都是对的，最后只不过是验证每一部分都是正确的串联起来了而已，这点相对来说，是很容易的。所以最后所需要的手动测试，可以少很多，顺利很多，也简单得多。
最后，是因为我懒
如前所述，如果没有单元测试的话，那就只有手工测试，把app运行起来，如果有错的话，改一点东西，再运行起来。。。这个过程太漫长太痛苦，对于一个很懒的人来说，如果能写代码来代替手工测试，每次写完代码只需要按一次快捷键，就可以直接在IDE里面看到结果，那是多爽的一件事！所以冲着这点，我也不想回头。我记得上一次使用“把app运行起来”这种开发方式，还是因为调试一个动画效果。因为动画效果是很难单元测试的，那就只有改一点代码，跑一边app，觉得不对，再改一点，跑一边，这样来来回回反反复复，那感觉真是。。。
单元测试给我带来了什么
前面讲了为什么我要写单元测试的原因，接下来讲讲用了单元测试这种写代码的方式以后，给我带来什么样的好处。这根前面讲的“原因”有部分重合的地方，然而也有不一样的地方。
更快的结果反馈
这点前面讲过了，有单元测试的帮助，我可以写完一个独立的代码单元，就立刻验证它的正确性，这跟需要完成所有代码再把app运行起来手动测试相比，是一个更快的反馈循环，能更快的发现代码是否正确，也更快的得到一种成就感。
更少的bug，或者说更快的发现bug
正如上面所说，我们没有做这样的前后统计，来证明有了单元测试以后，我们app的bug少了多少。然而，我自己的经验是，我已经不知道多少次以为只是做了一点小改动，不会有任何问题，结果一跑单元测试，发现还是改出问题来了。从这点来说，单元测试帮助我发现了不少问题，至少是更快的发现了问题。很多时候，这些问题是因为不小心疏忽了而导致的。然而话说回来，大部分bug不都是因为不小心疏忽了，很多情况考虑到，或者是考虑错了而导致的吗？你或许会觉得，自己很厉害很专业，一定不会有这种“疏忽”，写的代码一定是没有bug的。然而事实是，再厉害的人，都有状态不好的时候，都有情绪不高的时候，都有感觉比较累的时候，都会受到或多或少外界的干扰，这种时候都是很容易犯错的。这个跟厉不厉害，专不专业其实没有关系。李世石多么专业，在跟AlphaGo比赛的时候，不是依然会失误，会犯错吗？这个时候如果有那么一层保障，来防止你不小心犯错，岂不是更好的一件事情？
对于安卓开发来说，一遍一遍的运行app，再执行相应的用户操作，看界面是否显示正确的结果，通过这种方式来测试自己的新代码、重构是否是正确的，这是非常浪费时间的一件事情，而且效果还不好。有了单元测试，我现在开发过程中几乎已经不用把app运行起来了，速度相对来说快多了。此外，因为单元测试能帮我减少bug，从而也减少了调试bug，fix bug的时间。一个切身感受是，自从开始写单元测试以后，我启动AndroidStudio的debugger的次数明显减少了。这也是单元测试节约时间的地方。当然，这个结论也是自我感觉的结果。写单元测试需要时间，这也是不能否认的事情，至于有单元测试是否真的更快，快了多少，我没有具体的统计数据，所以很难给出一个确切的答案。这里需要重点说一下的是，你为新代码写的单元测试，不仅仅是能在目前你这次写新代码的时候起了作用，它的作用更体现在以后重构代码的时候，你可以很快速，很安全的进行重构。这点往往大家会忽略，所以会觉得在单元测试上花费的时间“不值得”。
更好的设计
当你为自己的代码写单元测试的时候，尤其是采用的方式，你会很自觉地把每个类写的比较小，功能单一，这是软件设计里面很重要的原则。此外，你能把每个功能职责分配的很清楚，而不是把一堆代码都塞到一个类里面（比如Activity）。你会不自觉的更偏向于采用组合，而不是继承的方式去写代码。这些都是很好的一些代码实践。至于为什么TDD能够改善代码的设计，网上有很多的文章去分析和论证这个结论。我看到比较印象深刻的一句话是（具体在哪看的搜不出来了）：当你TDD的时候，你是从一开始，就从一个代码的使用者，或者说维护者的角度，去写你的代码。这样写出来的代码，自然会有更好的设计。
更强的自信心
有单元测试来保证你的代码是对的，这对于你写代码、发布代码、重构都提供了信心保证，没有那么多的担心，从而工作起来也更快乐更开心。做人呐，最重要的是开心。。。而开心，也能让你变成一个更好的程序员。
没有时间写单元测试？
前面大概讲了讲我为什么要写单元测试，以及单元测试给我带来的好处，这些其实如果大家去google “why unit testing”，估计会得到类似的答案，然而依然会有很多人不写单元测试。如果问为什么的话，那么得到最多的回答，估计是：没有时间。那么，写单元测试真的需要很多时间吗？为什么多数真正写过单元测试的人会说，写单元测试可以节约时间呢？在这里，首先要承认两点。。。
1. 单元测试，的确是一门需要学习的技术。
不仅需要学习，而且你要学习的东西还真不少，你要学习的使用，你要学习的使用，的使用，的概念和使用等等等待。此外，在刚开始的时候，你的确也会遇到很多坑，现有代码的坑，Android的坑，Robolectric的坑等等。这个在安卓开发这边显得更是如此，因为Android开发环境是公认的最不利用写单元测试的环境之一。你需要花一些时间去学习如何处理，或者是绕过这些坑。
2. 在一个现有的，没有单元测试的项目里面加入单元测试，会需要一段时间的调整。
一个有单元测试的项目，跟一个没有单元测试的项目相比，结构会有比较大的不同。因此刚开始，你会发现各种不顺利的情况，你需要去调整各部分的代码，让他们变的容易测试，这也是比较花时间的地方。这种调整值得吗？我认为是值得的，因为容易测试的项目，往往意味着更灵活，更具备扩展性，这个前面已经提到过了。所以本身这件事情就是一件值得做的事情，更何况，测试本身又是一件非常有价值的事情。
然而等跨过了这两道坎，单元测试还需要花很多时间吗？根据我自己的经验，我觉得其实不是这样的，因为等你熟悉了如何写单元测试以后，要对一个类、一个接口写单元测试，是很容易的一件事情。如果你发现一个类不好测，往往是因为这个类的设计是有问题的。此外，你可以慢慢的搭建自己的一套测试框架，简化一些常用的繁琐的写法，让写单元测试变得更简便快捷。再加上前面讲述的原因，总体来说，我觉得写单元测试非但不会需要跟多时间，反而会节约时间。
这篇文章简单讲述了，为什么要写单元测试。其实，单元测试的必要性，看看那个知名的就知道了。在前20本中，所有5本讲述“如何写出更好的代码”的书，无一例外都强调单元测试的必要性。
Code Complete
The Pragmatic Programmer
Refactoring: Improving the Design of Existing Code
Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin
Working Effectively with Legacy Code by Michael C. Feathers
希望这篇文章，能让你多一点学习和实践单元测试的决心，因为这真的是非常值得拥有的一项技能，只是刚开始的时候，需要多一点点时间而已。
最后，如果你对安卓单元测试感兴趣，欢迎加入我们的交流群，因为群成员超过100人，没办法扫码加入，请关注下方公众号获取加入方法。
参考链接：
一个每年读200本书的安卓程序员
公众号：小创作输入关键字进行搜索
许多开发者都有个习惯，常常不乐意去写个简单的单元测试程序来验证自己的代码。对自己的程序一直非常有自信，或存在侥幸心理每次运行通过后就直接扔给测试组测试了。然而每次测试组的BUG提交过来后就会发现自己的程序还存在许多没有想到的漏洞。但是每次修改好BUG以后还是怀着侥幸心理，认为这次不会有 bug了。然后又一次自信地提交，结果又败了。因为这样反复几次后。
开发者花在找BUG和修复BUG的这些时间加起来已经比他开发这个模块花的时间还要多了。虽然项目经理已经预留了修改BUG和单元测试的时间。但是开发者却习惯性地在写好代码后就认为任务完成了。然后等问题出来了bug改了很多次还是修复不了的时候才和项目经理说“我碰到预想不到的问题，可能要延期发布我的代码“。如果这个项目不可延期，痛苦的加班就无法避免了。
为什么有这么多的BUG开发者却没发现呢。其实开发者是人又不是机器。人非圣贤孰能无过。BUG是不可避免的，只是每次在修复一个BUG之前基本上无法知道这个BUG是哪段代码引起。每次定位BUG可能会耗去你一个小时还是一天，这还要取决于你的水平了。
但是如果你的每段核心程序都有单元测试代码，你将不需要靠你的经验去判断或猜测BUG是由哪段程序引起，你只要运行你的单元测试方法。通过简单判断测试方法的结果就可以轻松定位BUG了。所以从表面上看，为每个单元程序都编写测试代码似乎是增加了工作量，但是其实这些代码不仅为你织起了一张保护网，而且还可以帮助你快速定位错误从而使你大大减少修复BUG的时间。而且这还有利你的身体健康，你将不会因为找不出BUG而痛苦不已，也将不用废寝忘食地加班了。而且项目的进度也将尽在掌握。
其实单元测试不仅能保证项目进度还能优化你的设计。有些开发者会说，写单元测试代码太费劲了，比写业务代码还麻烦。可是如果强迫开发者必须写单元测试代码的时候，聪明且又想‘偷懒’的开发人员为了将来可以更方便地编写测试代码，唯一的办法就是通过优化设计，尽可能得将业务代码设计成更容易测试的代码。慢慢地开发者就会发现，自己设计的程序耦合度也越来越低，每个单元程序的输入输出，业务内容和异常情况都会尽可能变得简单。最后发现自己的编程习惯和设计能力也越来越老练了。
其实容易测试的代码基本上可以和设计良好的代码划等号。因为一个单元测试用例其实就是一个单元的最早用户。容易使用显然意味着良好的设计。
有着良好设计的项目一直是很注重代码重用的。要做到代码重用首先要保证被重用的单元程序必须是个非常优秀的程序，除了良好的设计，还要有详细的文档。另外最重要的其实是单元测试代码。
单元测试代码还可以通过简单的事务回滚功能在生产环境上做基于真实数据的测试而不用担心会产生不必要的数据。利用这样的测试代码我们可以在发布程序后 check 刚才的发布是否成功。
很多研究结果表明，bug发现的越晚，修改它所需要的成本就越高，因此从成本角度来看，应该尽可能早地查找和修改bug。或许有人会有异议？程序员把bug 全找出来了，测试组干嘛？其实测试组进行的是集成APP测试，这样的测试无法全面的考虑到每个单元被调用时用的各种输入参数。就像一辆汽车，对每个零件进行测试是必须的。对组装好的汽车进行测试是无法代替每个零件的单独测试。或许对组装好的汽车进行测试可以发现某些零部件的问题。但是这个时候发现了问题就需要把汽车拆了换零件再装上。造成的成本可想而知。
要回复问题请先或
关注: 1 人