#20 楼 @owenfigo 现在已然是测试到质量的转变。光靠测试已经不能保证产品质量了

@jake20001 spring 的类啊

关于对测试数据的恢复。我之前一直在 docker 和 assertJ 的 changes 做抉择。后来还是选择了 assertJ 的 changes。 我想请教下楼主，重新运行 container 的时候，你是通过什么方式去判断数据库已经 ready 了呢？自悬等待？ 还是别的方式？

#15 楼 @u1465884394 哦哦 原来是这样啊

#13 楼 @u1465884394 额，但凡有端口号的服务都能用啊。。。

#21 楼 @seveniruby 嗯，是的，我应该多跟他们沟通，尤其发邮件之前。

#3 楼 @jamesparagon 额，我真没有放炮的意思

#1 楼 @monkey 放吧~ 老大~

#21 楼 @jamesparagon 我明白了，你们的测试用例是链式结构。前一个脚本创造的数据留给下一个脚本使用。 这确实是很不好的方式。之后也很难改

#19 楼 @jamesparagon 嗯，如果你用第一种方式的话。其实性能上没什么影响。 用第二种，也就是测试用例运行结束后删除数据。是会慢一些。因为有很多的数据库操作。 针对这个问题，我是这么做的。不是每执行一个脚本都删除数据的。可以给用户留下策略让他决定运行一批 case 后再删除数据。这样就可以快一点。我是从框架角度做的。框架监控数据库， 根据用户设计的删除数据的策略来做。

@DataManage(baseData="testData/project/defaultProject.xls",recoveryStrategy=RecoveryStrategy.METHOD)
public class TestDeleteProject extends BaseCase {

就像上面这样，recoveryStrategy 决定了恢复数据的策略。 可以 method 级别，可以 class 级别。class 级别就是所有在这个类中的用例都结束后再恢复数据

#10 楼 @seveniruby 请教一下，我们现在项目刚开始，开发那边已经有 CR 流程了。 开发的老大觉得这可以保证质量。规定严格的执行。顺便说一下我们是 toB 的模式。 这样在早期就引入 CR 是会影响效率么？

#18 楼 @andward 嗯，我觉得还好吧。毕竟 UI 和接口都不是监控 git 分支变化驱动的。是定时驱动的，一天就跑那么几次。 慢一点就慢一点吧。 单元测试那， 为了提升速度我是建议他们用 mock 把持久化层 mock 掉。这样就能快一点

#17 楼 @jamesparagon 额，我没太看懂，你们老大反驳的点是？

#15 楼 @lihuazhang 这也是我追求的。

#16 楼 @andward 额。这个是我没说清楚。因为是我发给开发同学的邮件。默认我们都熟悉分支策略了。其实我们的开发是在 feature 分支上开发完后 merge 回 develep 分支。然后我只测试这个分支的。而且环境也不是开发搭建。我自己可以在本地 debug 的，我都有 git 权限

#8 楼 @seveniruby 感谢。我太偏激了

#11 楼 @lihuazhang 抱歉哈我当段子写的

我来结帖吧。统一回复下。抱歉让大家感到不适了。本来就是当段子写的。我这人没心没肺的。总容易得罪人

#10 楼 @seveniruby 我现在还担心发这么个邮件是不是得罪开发同学了哈哈

#12 楼 @nicoc 恩。我承认我沟通有问题。昨天没怎么想就发邮件了

#8 楼 @chenhengjie123 嗯，明天上班以后，尽量跟开发的同学们沟通吧。希望能说服他们。

#5 楼 @chenhengjie123 我觉得我现在的职位比较尴尬，其实没啥权利，凭什么对人家开发指手画脚呢。开发的同学们应该会这么想吧