业务逻辑封装原则

业务逻辑封装原则就是严格分离测试逻辑和业务逻辑

这里的测试逻辑就是指Testcase里面的逻辑，业务逻辑就是产品功能相关的逻辑。

这个原则看上去很简单明了，但是实践时非常容易把二者混淆。

为了“严格分离测试逻辑和业务逻辑”，我对开发人员的角色进行了划分，分为“framwork开发人员”和“testcase script开发人员”。framework开发人员在开发封装业务逻辑的API的时候，心里要忘掉任何具体的某个testcase的测试逻辑，而只关心如何能从产品业务逻辑的角度提供最合适的API。

其次，我还对函数所在的位置进行了隔离。所有业务逻辑封装的代码放在函数库目录里，而与测试逻辑相关的一些共享函数放在TestCase repository目录里。

即便如此，开发人员也会遇到“不能确定一个function是属于业务逻辑还是测试逻辑的问题”。我举了两个个例子。

·        验证用户存在

验证用户存在是一个经常会用到的功能，所以对于开发人员有极大的诱惑把它封装为一个函数，放在framework里。但实际上这是错误的，因为“验证”这个动作本身就与业务逻辑无关，而属于测试逻辑。

·        创建一组特定的“角色，用户，用户组”

在某件些testcase的前置条件里，要求一组特定的“角色，用户，用户组”存在。写一个函数封装这一系列操作是一个好主意，但这个函数仍然属于测试逻辑。因为对于产品来说，并没有一组“角色，用户，用户组”这个概念。