开发测试中的奇葩案例

在一次与老友的沟通中，谈到了在促进开发者测试中遇到的一些奇葩事情。作为测试人员，去调侃开发是一件类似猴子互相捉虱子一般的社交行为需要，因此试记录之。

1）关于断言
测试用例能不能通过，除了用例能正确执行之外，还需要对预期结果进行断言。
为了应对公司要求单元测试的开展，有开发同学就写下了类似

@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. 
}

看来颇得老子无为的真传。

开发自测==？

在某些低级别的系统中，并不会投入专职的测试人员，只是由开发人员进行自测。 由于没有进行交叉测试等实践，其自测质量只能靠那个开发人员的个人职业操守了。测试/运维人员对这部分系统的要求就是：在关二爷的庇佑下，能成功安装、部署。

我们是测试驱动开发的模式

在很多团队以及开发部门负责人口中，多少都听到过类似的言论。 真正了解下来，有以下两个场景
1）（手工）测试驱动开发
2）代码库中没有可执行的测试用例

单元测试vs 系统测试

比起单元测试，我们更希望做端到端的测试，这样我对系统质量有更高的信心。
（接下来是一段关于因为各种原因没有做端到端测试的论述......）

关于测试代码的需求

1） As a developer, I hope单元测试的代码能够另外建一个代码库，或者提交到别的分支, When 我重构我的代码后， 我的项目能够编译通过，而不会因为单元测试用例无法编译导致整个项目的编译失败。So 我可以继续下一项开发任务了。