技术、思考，写点会让自己点赞的东西。

昨天开始看《Build Awesome Command-Line Applications in Ruby 2》这本书，看完第一章。其中提到一个Awesome的Command，应该是功能单一（single-purpose）的，但是具体什么叫功能单一呢？为了解释这个问题，书中举了两个反例，来解释什么不是功能单一。 第一个例子是一个备份数据库的脚本。其中需要备份的数据库有两个，这个脚本一次性把两个脚本都备份了，脚本大概是这么写的： #!/usr/bin/env ruby # File: db_backup.rb #两个数据库的信息 databases = { big_client: { database: 'big_client', username: 'big', password: 'big', }, small_client: { database: 'small_client',…

这是一个对railscast250的学习笔记，所有copyright belongs to Railscast作者 Ryan Bates ### 1. 创建User Model rails g resource user email password_digest 这里有两点说明，一是关于rails g resource，你可能对rails g scaffold熟悉，那resource是什么呢？在这里，scaffold和resource都是rails generator，就是可以帮你自动生成很多琐碎的东西的助手，这样你就不用自己一遍一遍写类似的东西了。resource跟scaffold最主要的不同是，resource不会帮你生成对应的controller里面的任何个action以及他们对应的任何view；第二点需要说明的是“password_digest”这个字段，这个字段比较关键，因为接下来我们要用到rails为我们提供的has_secure_password这个helper method，这个method默认需要用到这个字段。 ### 2. Migrate database 在命令行执行rake db:migrate创建你的database ###…

这是被问得最多的问题之一。。。 问题 今天讲一个我们讨论群里面被问得最多的一个问题：怎么测试异步操作。问题很明显，测试方法跑完了的时候，被测代码可能还没跑完，这就有问题了。比如下面的类： public class RepoModel { private Handler mUiHandler = new Handler(Looper.getMainLooper()); public void loadRepos(final RepoCallback callback) { new Thread(new Runnable() { @Override public void run() { try {…

The Old Way 我们在系列的第六篇文章前面介绍了Dagger2在单元测试里面的使用姿势。大致过程是这样的，首先，你要mock出一个Module，让它的某个Provider方法在被调用的时候，返回你想到的mock的Dependency。然后使用这个mock的module来build出一个Component，再把这个Component放到你的ComponentHolder。举个例子说明一下，假设你有一个LoginActivity，里面有一个LoginPresenter，是通过Dagger2 inject进去的，如下： public class LoginActivity extends AppCompatActivity { @Inject LoginPresenter mLoginPresenter; @Override protected void onCreate(Bundle savedInstanceState) { //...other code ComponentHolder.getAppComponent().inject(this); } } //对应的Test类如下： @RunWith(RobolectricGradleTestRunner.class) @Config(constants = BuildConfig.class,…

注： 如果你还不了解Mock的概念或Mockito框架的使用，请先看这篇文章。 @Mock的基本用法 如果你follow了这个安卓单元测试系列文章，那么到现在为止，你应该很清楚mock的概念和使用了，创建Mock的方法我们都知道： YourClass yourInstance = Mockito.mock(YourClass.class); 比如： public class LoginPresenterTest { @Test public void testLogin() { UserManager mockUserManager = mock(UserManager.class); PasswordValidator mockValidator = mock(PasswordValidator.class); Mockito.when(mockValidator.verifyPassword("xiaochuang is handsome")).thenReturn(true); LoginPresenter…

相信写Android的，写Java的人应该都听说过RxJava这个革命性的东西了，很多人也了解这个东西怎么使用。网上也有很多优秀的介绍性的文章，如果你还不了解这个东西，或者是不熟悉它的用法的话，我会建议先看这个系列的文章，然后再看这篇。尤其是后者绝对强烈推荐，其实我个人对RxJava的看法，刚开始只是觉得这个东西写起来语法非常简洁，非常优雅，可以在很大程度上面减少一些外部变量的使用，非常Functional。但是等到我看了那篇文章以后，我才发现，我只是发挥了RxJava不到一成的功力，获得了它不到一成的优点。它还有那么强大的力量，隐藏在冰山水下。另外，国内也有广受好评的扔物线写的给Android开发者的RxJava详解。这些足够让你对RxJava有一个比较深入的了解，此外，扔物线的文章也有一定程度的原理讲解和源码分析，可谓真正的深入浅出。 Anyway，这里我们就不介绍RxJava的用法和特点了，我们简单看看它的源代码。 先看第一部分，Observable的创建。现在大部分介绍RxJava的文章、尤其是介绍RxJava在Android上面的使用的文章，都往往会结合第三方的library，比如Retrofit。里面介绍Observable的使用方式是通过Retrofit的返回结果来获得一个Observable，再操作这个Observable。这容易给我们一种错觉，就好像我们自己从来不用，也不能创建Observable一样。然后其实不是这样的，我们完全可以自己创建Observable。常见的创建Observable的方式有以下几种： Observable.just(...) 比如： Observable.just("xiaochuang"); //Create an Observable that has only one item: "xiaochuang" Observable.just("xiaochuang", "handsome"); //Create an Observable that has 2 items: "xiaochuang" and "handsome" Observable.just("xiaochuang", "is", "handsome");…

端午节开始看这本编程领域经典的书《Working Effectively with Legacy Code》，中文版叫《修改代码的艺术》。英文原版豆瓣评分9分，中文版8.2分。Amazon.com评分9.2分。 从评分上看，这是一本质量非常不错的书。中文版的书名翻译虽然少了点感觉，多了点俗气——现在书名动不动什么什么艺术，什么什么之道，甚至什么什么之禅，真是让人不知道该作何感想。但应该说，这个书名翻译得还是很准确的。因为这本书讲的就是如何修改代码！ 书的开篇讲了修改代码的四种原因： Adding a feature Fixing a bug Improving the design Optimising resource usage 对于前两种原因来说，改代码自然是理直气壮，没什么可以商量的余地。然而，对于后两种原因，通常就不是那么肯定了，甚至还有种policy叫做“If it’s not broke, don’t fix it”。这种policy之所以会出现，自然是有它的原因的。最大的原因，往往不是因为改代码需要时间，而是因为更改是有风险的，这种风险就是，你不知道你的更改是不是对的，更要命的是，你不知道你的更改会影响到其它的什么地方，会后带来什么后果。出于这种恐惧的心理，我们往往倾向于不到非不得已，就不去改代码。而这里所说的非不得已，就是添加feature和fix bugs。 然而遗憾的是，这种policy被一次又一次的证明，是行不通的，因为很快你会发现，你的每个类会写得越来越大，每个方法越来越长，结构越来越复杂，越来越难以理解，每次加一个新feature，fix一个bug都越来越困难。于是到了某个点，所有东西都必须推倒重写。这种事情在历史上发生了一次又一次。那怕不会到那一步，烂代码和烂结构也会严重的拖后正常的工作进程。 这种结局是应该被避免的，也是可以被避免的，怎么避免？那就是不要只顾着add feature和fix…

单元测试是个技术活，它有自己的一套知识体系，要做好单元测试，的确是需要学习和不断的在实践中练习的。好消息是，这套知识体系的范围相对来说是有限的，因此，只要耐心的学习和练习一段时间，就可以做好日常大多数的需求。然后国内这大环境和氛围，大家都清楚，大部分时候大家都在赶feature，赶上线，以至于单元测试这件事情，往往被忽略，甚至从来没考虑过，而这一点在移动开发上面则更加严重。这导致的结果就是，网上很难找到比较系统的关于单元测试各个方面的文章。这就让有些童鞋那怕有做单元测试的想法，却不知道从何下手，因此导致一个恶性循环。 出于这点原因，我根据自己的一些经验和想法，写了一个系列的文章，至此为止写了7篇，然而经常发现有朋友对前面的一些概念不是很清楚，从网站或公众号找之前的一些文章又不是很方便，因此整理了这样一篇汇总性的文章，希望能让大家对此有个更整体化的了解，如果某一方面的东西不是很清楚，也能很快找到参考。 以下文章是这个系列文章的总结。 什么是单元测试：介绍了什么是单元测试，里面澄清了一个最常见的误解，同时介绍了有返回值和没有返回值两种不同的函数——对于OO来说，应该叫“方法”，但是中文里面“方法”这个词太容易产生误解了，因此我这里用函数来代替，这就是翻译尴尬的地方。所以很多时候我建议不如直接用英文单词本身，而不是非要硬生生翻译过来。 为什么要做单元测试：对于什么要做单元测试的个人之见。 JUnit单元测试框架的使用：介绍了题目中说的内容，JUnit是最基础的一个单元测试框架。 Mock以及Mockito的使用：mock自古以来就是单元测试不可分割的一部分，这篇介绍了mock的概念和使用。 依赖注入，将mock方便的用起来：为了将mock更方便简洁优雅的用起来，我们需要用到依赖注入。这篇文章介绍了依赖注入的概念和使用。 使用dagger2来做依赖注入，以及在单元测试中的应用：上一篇文章讲了依赖注入，而Dagger2能让我们易如反掌的使用依赖注入的模式，代码的耦合度变得非常低。 Robolectric，在JVM上调用安卓的类：解决在JVM上做单元测试的时候，无法调用和测试安卓的类的问题。 其它的一些文章： Android单元测试在蘑菇街支付金融部门的实践：这个是在InfoQ的移动前线学习分享群里面作的一个分享，首发于”移动开发前线”公众号，也在InfoQ网站上发表过，讲了的单元测试在蘑菇街支付金融部门的实践。 MDay上的分享-关于安卓单元测试的一切：这是在MDay第五季作的一次分享，有PPT和视频，不过视频暂时还没有公开，如果公开了会第一时间更新过来。 安卓单元测试是不是只有这些东西？当然不是，只不过，主要的概念和框架都在这了。剩下的相对来说更多是一些具体的技巧、解决某个具体问题的方法等等。对于这些东西，以后也会有文章介绍，敬请关注。 最后，如果你对安卓单元测试感兴趣，欢迎加入我们的交流群，因为群成员超过100人，没办法扫码加入，请关注下方公众号获取加入方法。 以上，希望能帮助到你。如果觉得有用，请分享一下，以便帮助到其它人。分享是一种美德，这也是我坚持写作的初衷。 (如果提示群满了，请关注一下公众号，在公众号的菜单有加入方法) 关注公众号，加入单元测试交流群

今天讲讲Android上做单元测试的最后一个难点，那就是在JVM上无法调用安卓相关的类，不然的话，会报类似于下的错误： java.lang.RuntimeException: Method isEmpty in android.text.TextUtils not mocked. 关于这个话题，其实我以前是写过的，也许今天我回过头来写这个话题，会采用不一样的形式，不一样的心态来写，然而，作为我写过的第一篇关于单元测试的文章，而且看看时间，是去年的6月15号，再过几天，刚好一周年。想想这篇文章是在我刚开始探索，尝试在安卓上面写单元测试的时候，写的一篇文章，如今因为安卓单元测试的原因，我认识了很多同行，甚至不时有人叫我“大牛大神”之类的，虽然知道大家是客气，我也受之有愧，但怎么滴心里也有点虚荣的开心，哈哈哈。。因此现在回过头去看看当时自己写的东西，不禁觉得有点那啥。。。因此，我决定把之前的文章稍作补充和修改，作为这个系列的第七篇。 ----------------------以下文字写于去年今天----------------------- 作为一只本科非计算机专业的程序猿，手动写单元测试是我从来没接触过的东西，甚至在几个月前，我都不知道单元测试是什么东西。倒不是说没听过这个词，也不是不知道它的大概是什么东西——“用来测试一个方法，或者是一小块代码的测试代码”。然而真正是怎么做的？我并没有一个概念，或者说并没有一个感觉。 记得第一份工作在创新工场的时候，听当时的boss说，公司有个神级的程序员，他会写大量的单元测试，甚至50%以上的代码都是单元测试。当时崇拜之极，却仍然觉得写单元测试是很麻烦的一件事情。 扯远了，话说回来，当你接触多了国外的技术博客，视频之后，你会发现，单元测试甚至TDD，在国外是非常流行的事情。很多人甚至说离开了单元测试，他们便没有办法写代码。这些都让我对单元测试的好感度逐渐的上升。然而，真正让我下定决心，一定要研究一下这个东西的，是前段时间看大名鼎鼎的《重构：改善现有代码的艺术》里面的一段话： I've found that writing good tests greatly speeds my programming, even if I'm not refactoring. This was…