熊节：极限追问 038

【测试要改数据库，怎么办？】

背景：在某群里看见这样一个问题：「请教一个问题，在对service层做单元测试时候，是往insert数据库一条数据，假如这种情况在jenkins打包跑单元测试时候，数据库不就多了条数据吗，这种情况怎么处理？」

分问题1:你从这个问题中看到哪些槽点？

分问题2:作为极限编程实践者，你会给这位同学什么建议？

Page

【测试要改数据库，怎么办？】

背景：在某群里看见这样一个问题：「请教一个问题，在对service层做单元测试时候，是往insert数据库一条数据，假如这种情况在jenkins打包跑单元测试时候，数据库不就多了条数据吗，这种情况怎么处理？」

分问题1:你从这个问题中看到哪些槽点？

（1）什么是单元测试？ （2）单元测试中的单元是什么？ （3）单元测试测什么？ （4）单元测试和数据库测试的有什么区别？ （5）先写单元测试还是先写数据库测试？ （6）数据库测试是不是可以用内存数据库代替？ （7）当前测试执行过程中insert一条数据，是不是可以在执行完之后teardown？ （8）Jenkins在执行测试环节做了哪些操作?

分问题2:作为极限编程实践者，你会给这位同学什么建议？

（1）复杂问题变得简单可以通过问题拆解。所以要真的弄清楚单元测试是什么？单元测试测什么？ （2）除了能够写代码，拓展一些工具，来让项目或者自己开发效率更高。 （3）熟悉你的测试工具。例如Junit5提供了哪些支持测试实践的功能点，它们可以怎么组合使用 （4）弄清楚当前项目是怎么分层的。比如分了基层，service是职责是什么。 （5）既然用到了Jenkins，那么现在遇到这个问题，自己的考虑是什么，有哪些解决这个问题的思考和思路。

冯

【测试要改数据库，怎么办？】

背景：在某群里看见这样一个问题：「请教一个问题，在对service层做单元测试时候，是往insert数据库一条数据，假如这种情况在jenkins打包跑单元测试时候，数据库不就多了条数据吗，这种情况怎么处理？」

分问题1:你从这个问题中看到哪些槽点？

数据库测试不应该在单元测试中进行，单元测试专注测试业务逻辑。 连接数据库的测试会运行的很慢，影响节奏，应该放在集成测试。

分问题2:作为极限编程实践者，你会给这位同学什么建议？ 建议： 1.mock数据库 2.集成测试时，在集成测试环境用docker拉起数据库，测试完毕后释放

Flynn

【测试要改数据库，怎么办？】

背景：在某群里看见这样一个问题：「请教一个问题，在对service层做单元测试时候，是往insert数据库一条数据，假如这种情况在jenkins打包跑单元测试时候，数据库不就多了条数据吗，这种情况怎么处理？」

分问题1:你从这个问题中看到哪些槽点？

槽点： 真实数据库产生了垃圾数据

分问题2:作为极限编程实践者，你会给这位同学什么建议？ 建议： 1.通过mock模拟数据库所需依赖 2.创建内存数据库供测试单独使用 3.所有的测试不会影响到真实的数据库，确保不会有任何副作用

枫中的刀剑

分问题1:你从这个问题中看到哪些槽点？ 单元测试不应该触及实际的数据库操作。如果数据库是真实环境，那么测试数据就不应该写入其中。

分问题2:作为极限编程实践者，你会给这位同学什么建议？

在实际的单元测试中，应该对数据源进行抽象。仅对接口验证，减少测试对象的耦合，提高测试速度。

数据库的测试应该放到集成测试中，采用gradle多版本构建的方式，建立数据源接口的虚假实现。避免对生产数据库进行操作。

陈旭

【测试要改数据库，怎么办？】

背景：在某群里看见这样一个问题：「请教一个问题，在对service层做单元测试时候，是往insert数据库一条数据，假如这种情况在jenkins打包跑单元测试时候，数据库不就多了条数据吗，这种情况怎么处理？」

分问题1:你从这个问题中看到哪些槽点？ 我们单元测试一般只测试代码逻辑，涉及到三方api，或者数据库接口，一般mock掉。如果真的需要测试service层，建议放在集成测试里，可以做好上下文管理，比如xUnit语法可以用setup, teardown确保数据库没有遗留测试数据。

分问题2:作为极限编程实践者，你会给这位同学什么建议？ 单元测试最好要职责明确，测自己的代码逻辑，摆脱外部依赖。在集成测试，冒烟测试，等测试里测试服务，并通过上下文管理确保资源回收干净。