本节课我有以下几点体会：
1、从开发者的视角看编码和测试是不分家的，是可以通过重构形成良性生态圈的，类似之前课程中的反馈模型和红绿重构模型；
2、A-TRIP是个很好的总结和行动指南，在今后工作中应一以贯之，把工作做到扎实有成效；
3、对文中提到的数据库依赖的问题，我也说说自己的浅见。我觉得在测试代码中尽量避免与数据库打交道，测试更关注领域与业务，往往爆雷更多的是resource和service，模型的变化往往牵动着表结构的变化，与其两头兼顾不如多聚焦模型，我常用的做法是用例配合若干小文件(数据忠实于模型)，保证库操作临门一脚前所有环节都是正确的，同时方便适应变化。一旦出现异常，也比较容易定位是否是数据库操作引发的问题。
 (此点基于工作中发现项目型程序员大多是先急于把表结构定义出来，好像不这么做写代码就不踏实)

我还是习惯先写代码 在写测试 如 有一个投资机会详情（opportunities/{id}）的功能

首先是大的步骤任务拆解

- 查询机会基本信息
- 查询机会参与方（标的方、投资方）信息
- 相似推荐 即推荐与该机会类似的机会
- Domain ==> VO

然后是每个大步骤再细分 如
- 查询机会基本信息
    - 调用机会Service getById() 获取基本信息
    - 调用机会Mappper getById() 获取基本信息
    - 机会Mapper.xml 写查询sql
    - 机会Mapper单元测试
        - 准备机会数据 setUp/before中
            - 一个有效机会1
            - 一个无效机会2
            - 一个有效机会3

        - 测试getById(1) 能正常查询 并且页面上需要展示的字段都有
        - 测试getById(2) asertNull()

然后后面就是按部就班的开发了 我是从上往下进行开发的(或者说是从始到终进行开发的) 即先开发Service 再开发Mapper

开发完一个打个勾
- - 调用机会Service 获取基本信息 ✅

Mapper这一层的测试 直接连到是一个测试库 回滚依赖的是Spring自带的回滚机制

假设实际代码中只需查询 无需插入 那么会专门在该测试类中新建一个额外的Mapper 用于插入测试数据
如
class FooMapperTest {
    @Before
    public void setUp(){
        testMapper.insert(1, 1, "name1");
    }
    
    interface FooTestMapper{
        @Insert("...")
        void insert(int isvalid, int id, String name, ...)
    }
}

service controller级别的测试 通过Mock的方式来测试

现在觉得是不是测的有点过于细了 比如 返回的行业 数据库中是逗号分割的字符串 返回给前端是一个行业数组 连VO中的的getIndustries()都测试了

assertNull(vo.getIndustries())
asserttArrayEquals(new String[]{"行业一","行业二"}, vo.getIndustries())