在一次与老友的沟通中，谈到了在促进开发者测试中遇到的一些奇葩事情。
作为测试人员，去调侃开发是一件类似猴子互相捉虱子一般的社交行为需要，因此试记录之。
关于断言
测试用例能不能通过，除了用例能正确执行之外，还需要对预期结果进行断言。
为了应对公司要求单元测试的开展，有开发同学就写下了类似
@Test
public void IamDoingTest(){
assertThat(1,is(equals(1)))
}
这样的用例来充数。
而另外一个案例是， 在翻开历史遗留项目的代码仓库时，可以惊奇地发现一个单元测试覆盖率颇高的项目（相对没有用例的项目而言），居然找不到一个断言，或者都是这样的断言：
@Test
public void IamDoingTestAgain(){
//assertThat()
// comment the assert because it casues failure if switched to another env.
}
看来颇得老子无为的真传。
关于执行
测试用例只有通过执行，才能统计覆盖率，代码才能提交。因此，可以有如下的套路，就写下了类似
@Test
public void IamDoingTestAgain2(){
try{
String result=service.callMethod()
System.out.println(result);
}catch(Exception e){
e.printStackTrace();
}
}
}
开发自测==？
在某些低级别的系统中，并不会投入专职的测试人员，只是由开发人员进行自测。由于没有进行交叉测试等实践，其自测质量只能靠那个开发人员的个人职业操守了。测试/运维人员对这部分系统的要求就是：在关二爷的庇佑下，能成功安装、部署。
我们是测试驱动开发的模式
在很多团队以及开发部门负责人口中，多少都听到过类似的言论。真正了解下来，有以下两个场景：
1）（手工）测试驱动开发
2）代码库中没有可执行的测试用例
单元测试vs 系统测试
比起单元测试，我们更希望做端到端的测试，这样我对系统质量有更高的信心。
（接下来是一段关于因为各种原因没有做端到端测试的论述......）
关于测试代码的需求
As a developer, I hope单元测试的代码能够另外建一个代码库，或者提交到别的分支, When 我重构我的代码后， 我的项目能够编译通过，而不会因为单元测试用例无法编译导致整个项目的编译失败。So 我可以继续下一项开发任务了。
源自公众号 软件测试那些事