RabbitMQ 服务器在安装之前需要安装 erlang。 最新版本的 RabbitMQ 3.8.0 需要 Erlang 21.3 以上的版本支持。 在这里，我们需要在你的 CentOS 中安装 Erlang 21.3.8.8 版本。 下载地址和软件更新 Erlang 21.3.8.8 版本的下载地址，请参考链接： https://packagecloud.io/rabbitmq/erlang/packages/el/7/erlang-21.3.8.8-1.el7.x86_64.rpm RabbitMQ 3.8.0 的下载地址，请参考链接：https://www.rabbitmq.com/install-rpm.html 使用登录上你的 CentOS 7 服务器后，首先需要查看你的服务器是否安装了 wget，如果没有安装 wget，请运行 yum install wget 进行安装。 yum install wget 当 wget 安装完成后，运行 yum update 来更新你的服务器。 安装 Erlang 首先你需要下载 Erlang ，然后进行安装，在上面提到的地址  https://packagecloud.io/rabbitmq/erlang/packages/el/7/erlang-21.3.8.8-1.el7.x86_64.rpm 中的右侧有一个 wget 的地址。 你可以运行 wget --content-disposition https://packagecloud.io/rabbitmq/erlang/packages/el/7/erlang-21.3.8.8-1.el7.x86_64.rpm/download.rpm 来进行下载。 当你下载到你的本地计算机后，运行命令 yum localinstall rabbitmq-server-3.8.0-1.el7.noarch.rpm 来安装你下载的 rpm 包。 当你安装完成后，你可以运行命令 erl -version 来查看你安装的 erl 版本。 在这里，你可以看到这显示的版本低 Erlang emulator 版本，与你下载的 Erlang 版本是不同的。 安装 RabbitMQ 运行下面的命令，将 RabbitMQ 下载到你服务器上。 wget https://github.com/rabbitmq/rabbitmq-server/releases/download/v3.8.0/rabbitmq-server-3.8.0-1.el7.noarch.rpm 当你下载完成后，你需要运行下面的命令来将 Key 导入。 rpm --import https://www.rabbitmq.com/rabbitmq-release-signing-key.asc 使用 yum 进行本地安装，运行命令： yum localinstall rabbitmq-server-3.8.0-1.el7.noarch.rpm 当安装完成后，你可以使用命令来启动 rabbitmq 服务器： systemctl start rabbitmq-server RabbitMQ 防火墙配置 RabbitMQ 的运行需要一系列的端口。因此你需要配置你的防火墙将下面的端口打开。 如果你使用的是 firewalld，那么请依次执行下面的命令。 打开防火墙端口： firewall-cmd --zone=public --permanent --add-port=4369/tcp firewall-cmd --zone=public --permanent --add-port=25672/tcp firewall-cmd --zone=public --permanent --add-port=5671-5672/tcp firewall-cmd --zone=public --permanent --add-port=15672/tcp firewall-cmd --zone=public --permanent --add-port=61613-61614/tcp firewall-cmd --zone=public --permanent --add-port=1883/tcp firewall-cmd --zone=public --permanent --add-port=8883/tcp 将防火墙配置重新载入： firewall-cmd --reload 绝大部分情况，当你执行完上面的命令后，你的 RabbitMQ 应该能够正常访问了。 如果你的服务器还启用了 SELinux 的话，你还需要执行下面的命令来让让 RabbitMQ 服务器能够接收发送网络数据： setsebool -P nis_enabled 1 RabbitMQ 设置自动启动 在安装完成后，我们希望 RabbitMQ 能开机自动启动。 请执行下面的命令，来让 RabbitMQ 随着计算机开机后自动启动： systemctl enable rabbitmq-server 使用下面命令查看 RabbitMQ 的进程运行状态： systemctl status rabbitmq-server 根据服务器的不同，会有不同的输出，我们的输出如下，表示 RabbitMQ 目前是正在运行的。 [root@vps263579 yhu]# systemctl status rabbitmq-server ● rabbitmq-server.service - RabbitMQ broker Loaded: loaded (/usr/lib/systemd/system/rabbitmq-server.service; enabled; vendor preset: disabled) Active: active (running) since Fri 2019-10-11 14:10:14 EDT; 9h ago Main PID: 14895 (beam.smp) Status: "Initialized" CGroup: /system.slice/rabbitmq-server.service ├─14895 /usr/lib64/erlang/erts-10.3.5.6/bin/beam.smp -W w -A 64 -MBas ageffcbf -MHas ageffcbf -MBlmbcs 512 -MHlmbcs 512 -MMmcs 30 -P 1048576 -t 5000000 -stbt db -zdbbl 128000 -K true -- -root /usr/lib64/erlang -progn... ├─15123 /usr/lib64/erlang/erts-10.3.5.6/bin/epmd -daemon ├─15259 erl_child_setup 32768 ├─15280 inet_gethost 4 └─15281 inet_gethost 4 RabbitMQ 启用 Web 管理界面 在默认的情况下 RabbitMQ 的 Web 管理控制台是没有启用的，你需要通过下面的命令来进行启用。 安装 Web 管理界面的插件： rabbitmq-plugins enable rabbitmq_management 提供 RabbitMQ 用户和对用户使用的权限进行赋权： chown -R rabbitmq:rabbitmq /var/lib/rabbitmq/ 分别执行下面的命令： rabbitmqctl add_user admin StrongPassword…

在 IntelliJ IDEA 项目运行的时候收到了下面的错误提示： Error running 'Application': Command line is too long. Shorten command line for Application or also for Spring Boot default configuration. 这时候你需要调整运行项目的配置，将 Configuration 中的 Shorten Command Line 修改为 JAR 就可以了。

总会有人继续开发的。 继续开发的那个人有可能就是你，你 Fork 一个，自己接着发布版本。其实更多的情况是优秀项目或者工具被某个公司或者个人，或者组织收编，然后公司根据前期版本 Fork 一个自己的版本，然后继续开发。 在这个过程中，有可能会 Merge 回老的版本，有可能就不会 Merge 回老的版本了，就以这个为基础继续开发就行了。 换句话说就是谁死了地球都照样转。 想想 MySQL，作者没挂，被 Oracle 收编后开发缓慢，原作者就弄了一个 MariaDB，其实很多代码与 MySQL 都一样。 例如，Oracle JDK 和 OpenJDK，不都差不多是这种关系吗？

如果说以前使用 SVN 或者 CVS 被弄掉了是很麻烦，因为所有代码都会集中放到服务器上。 一般来说 Git 使用的是分布式部署，所有人都会有一个代码仓库的完全拷贝，因此在极端条件下重新部署和恢复非常快，没有 SVN 那么麻烦。 GitHub 主动关闭的可能性不是很大，我们的问题主要是网络和信任的问题。要知道你的 Pull，Push 都需要进行网络交互，这个时候是有一定的网络流量的，在国内访问 Github 有多慢，那么外面要访问在科学上网内部的数据有多慢你应该也有体会。没有人愿意忍受经常性的 timeout。 毫无预警，毫无依据的账户禁用，代码删除，我相信没有人愿意接受。 毫无预警的查水表，这个是人都受不了。 毫无预警的网络暴力，粉红出征，让人心有余悸。 听过 ICP 认证吗？知道办下来有多难吗？ 有这几点，就把所有开发者的信心打击殆尽了，没有人愿意分享代码（怕不小心又踩谁的小尾巴了），与其搞那么复杂，还不如直接送 GitHub 方便。

希望在 GitLab 中对 2 个 branch 进行合并，如何创建 Pull Request 并且如何进行合并呢？ 在 GitLib 的 Web 界面中选择 Merge Requests 然后再界面中选择新建一个 Merge Request。 在左侧选择需要合并的 Branch，在右侧选择合并到的 Branch， 选择完成后单击按钮比较 branch 并且合并。   在弹出的界面中，单击提交合并按钮来进行合并   随后将会显示合并的按钮来进行合并，你需要单击这个按钮，否则的话是没有办法进行合并的。 然后你就可以看到状态被修改为合并了，你在分支中所有的修改将会合并到你希望合并到的分支中去了。 你可以将你不才需要的分支进行删除。

在 IntelliJ 的右下角，你可以看到当前的 Git 分支，然后你可以单击这个分支后，在弹出的界面的最上方有一个新建分支的选项。 然后再弹出的界面中，输入你要创建的分支名称后回车输入。 然后从项目中找到需要的 Git 选项，然后在仓库中选择 Push 在弹出的界面中，你可以看到 PUSH 的选项。 然后选择 PUSH 就可以了。 然后在远程仓库中，你可以看到你新创建的 Branch 已经 Push 上来了。        

Mockito 通过使用 equals() 这种自然的 Java 样式来校验参数值。有时候，当需要有其他一些灵活性的时候，你可能会要求使用参数匹配（argument matchers）。 请参考下面的代码： //stubbing using built-in anyInt() argument matcher when(mockedList.get(anyInt())).thenReturn("element"); //stubbing using custom matcher (let's say isValid() returns your own matcher implementation): when(mockedList.contains(argThat(isValid()))).thenReturn("element"); //following prints "element" System.out.println(mockedList.get(999)); //you can also verify using an argument matcher verify(mockedList).get(anyInt()); //argument matchers can also be written as Java 8 Lambdas verify(mockedList).add(argThat(someString -> someString.length() > 5)); 参数匹配运行进行灵活校验或者打标。 请访问 https://static.javadoc.io/org.mockito/mockito-core/3.0.0/org/mockito/hamcrest/MockitoHamcrest.html 链接来查看更多有关自定义参数匹配器/hamcrest matchers（custom argument matchers/hamcrest matchers）的内建参数匹配器和示例。 更多有关 自定义参数匹配器（custom argument matchers）的使用，请参考 ArgumentMatcher 类的 API 文档。 在使用复杂参数匹配器的时候需要谨慎。尝试给一个干净并且简单的测试的时候，尽量选择自然的参数匹配使用的是  equals() 对比相对偶然使用  anyX() 来说。有时候可能对你的代码进行一些重构来允许  equals() 进行匹配，或者可以实现（implement）equals()方法来帮助进行测试。 同时，请阅读 Capturing arguments for further assertions (Since 1.8.0) 页面中的内容，或者参考 ArgumentCaptor 类的 API。 ArgumentCaptor 是有关参数匹配器的是特殊实现，能够为后面的对比（assertions）捕获参数变量。 参数匹配器的写法 如果你现在正在使用参数匹配器，所有参数（all arguments）都必须由 matches 提供。 下面的示例代码显示校验，但是一些将会应用到打标中。 verify(mock).someMethod(anyInt(), anyString(), eq("third argument")); //above is correct - eq() is also an argument matcher verify(mock).someMethod(anyInt(), anyString(), "third argument"); //above is incorrect - exception will be thrown because third argument is given without an argument matcher. 像 anyObject(), eq() Matcher 方法不会返回 matchers。 在内部，他们将会在堆栈（stack）中记录一个 matcher 然后返回一个虚假的值（通常为 null）。 这种实现方式是基于 Java 编译器中有关静态类型的安全性问题而考虑的，从而带来的结果是你不能在 verified/stubbed 方法外部使用 anyObject(), eq()。   https://www.cwiki.us/display/MockitoZH/Argument+matchers

请参考下面有关于打标的代码。 //You can mock concrete classes, not just interfaces LinkedList mockedList = mock(LinkedList.class); //stubbing when(mockedList.get(0)).thenReturn("first"); when(mockedList.get(1)).thenThrow(new RuntimeException()); //following prints "first" System.out.println(mockedList.get(0)); //following throws runtime exception System.out.println(mockedList.get(1)); //following prints "null" because get(999) was not stubbed System.out.println(mockedList.get(999)); //Although it is possible to verify a stubbed invocation, usually it's just redundant //If your code cares what get(0) returns, then something else breaks (often even before verify() gets executed). //If your code doesn't care what get(0) returns, then it should not be stubbed. verify(mockedList).get(0); 在默认情况下，所有的方法都会有一个返回值。mock 函数默认返回的是 null，一个空的集合或者一个被对象类型包装的内置类型。例如，针对 int/Integer 将会返回 0，针对 boolean/Boolean 将会返回 false。 打标（Stubbing）可以被重写：例如一个通用的打标可以在启动的时候被确定（fixture），但是测试方法可以对其进行重写（override）。请注意重写的打标可能会在有很多标记的时候存在潜在的问题。 一旦被打标，方法将会总是返回已标记的内容，这个与这个方法被调用多少次无关。 最后的标记非常重要——当你对有相同参数的方法进行多次标记的时候。换句话说就是：标记的顺序是有关的（the order of stubbing matters），但是这个意义并不是很大。例如，这个只在标记完全相同的方法或者有时候参数匹配（argument matchers）被启用的时候，等情况下才会出现。, etc. 测试代码请访问 GitHub https://github.com/cwiki-us-demo/mockito-demo-java/blob/master/src/test/java/com/ossez/demo/mockito/MockitoStubbingTest.java 请注意，上面的测试代码在运行的时候回出现错误。 这是因为在测试代码运行的时候，我们尝试输出 mockedList.get(1)，这个在测试的时候，因为我们打标为抛出异常，所以这一句话将会在测试代码中抛出异常。 运行时候，抛出异常的界面如下：   https://www.cwiki.us/pages/viewpage.action?pageId=47843418

在下面的示例中，我们将会模拟（Mock）一个 List 列表。 这是因为绝大部分的人对列表这个接口比较熟悉（例如 add(), get(), clear() 方法）。 在实际情况中，请不要 mock list 这个类，你可用使用实际的实例来代替。 //Let's import Mockito statically so that the code looks clearer  import static org.mockito.Mockito.*;  //mock creation  List mockedList = mock(List.class);  //using mock object  mockedList.add("one");  mockedList.clear();  //verification  verify(mockedList).add("one");  verify(mockedList).clear(); 一旦创建完成后，mock 将会记住所有的交互。你可用选择校验任何你感兴趣的交互。 测试代码请访问 GitHub https://github.com/cwiki-us-demo/mockito-demo-java/blob/master/src/test/java/com/ossez/demo/mockito/MockitoBehaviourTest.java https://www.cwiki.us/pages/viewpage.action?pageId=47843416

为了能够持续改进 Mockito 和在未来提升测试体验，我们希望你能够升级到 Mockito 2.10！Mockito 按照语义化版本（semantic versioning）的方式对版本进行编排，并且只在主版本升级的时候包含有重大的修改。 在库的生命周期中，有时候重大升级是必要的，通常在重大升级中包含有很多重要的新特性，对老的库进行修改甚至有可能会修改 API。 有关完整的指南和一些不兼容的修改，请参考 What's new in Mockito 2 Wiki 页面中的内容。 我们希望能够享受  Mockito 2 带来的改进和便利。 Mockito Android 支持 在 Mockito version 2.6.1 中，我们原生包含 Android 支持（Android support）。 为了能够使用 Android 支持，添加 mockito-android 库到你项目的依赖中。这个 artifact 是 Mockito 项目组开发的，可以使用下面的的语法将依赖导入到你  Android 的项目中。 repositories { jcenter() } dependencies { testCompile "org.mockito:mockito-core:+" androidTestCompile "org.mockito:mockito-android:+" } 你可以通过在你的 testCompile scope 中使用 mockito-core 在常规虚拟机（VM）中运行相同的单元测试. 请注意，因为 Android 虚拟机的限制，你不能在 Android 中使用 inline mock maker。如果你在 Android 的测试中持续遇到问题，请访问官方的创建问题：https://github.com/mockito/mockito/issues/new 链接来向官方报告你遇到的问题。在向官方提交 Android 测试遇到的问题的时候，请同事提供你当前使用 Android 的版本和你项目中使用的依赖。 无配置 inline mock making 从版本 2.7.6 开始，我们提供了 mockito-inline 库。在这个库中，你可用不需要配置 MockMaker 扩展文件来启用 inline mock making 。 为了使用这个功能，请添加 mockito-inline 库来替换掉 mockito-core。 请参考下面的代码： repositories { jcenter() } dependencies { testCompile "org.mockito:mockito-inline:+" } 请注意，当 inline mock making 特性被默认整合到 mock maker 中的时候，这个库有可能会被取消。 有关更多的内容，请参考：Mocking final types, enums and final methods (Since 2.1.0) 页面中的内容。 https://www.cwiki.us/display/MockitoZH/Migrating+to+Mockito+2