上述 2， “你这个测试如果还 QueryModel 的子模块就不对了” -> "你这个测试如果还依赖 QueryModel 的子模块就不对了"

1. 对于这个单测来说，他依赖的只是 QueryModel 的 Query 方法；如果 QueryModel 是个接口的话，你随便注入一个实现他的就可以
2. 你这个测试如果还 QueryModel 的子模块就不对了；
3. QueryModel 如何初始化那是另外的事情，一般是在 Executor 实例化时初始化注入（ Golang 中推荐的实际是一个 struct 使用一个工厂方法来实例化)；单测时候直接注入 mock 的

常年梯子，一切正常

1Password + TimeMachine

```
type Executor struct {
q QueryModel
d UpdateModel
}

func (e Executor) Exec(v1 int, v2 string) int{
count := 0
if v1 > 10 {
e.q.Query(v1)
count += 1
}
if strings.HasPrefix(v2, "a") {
e.d.Update(v2)
count += 2
}
return count
}
```

兄弟 ，后续呢？持续围观中

这玩意还是别上别人的车吧，万一来个误操作就欲哭无泪了

四五年就个人经验是完全没有问题的，从 09 年到现在是第三台 MBP，前两台每台都是主力工作了四年多；现在都还可以正常使用；第三台现在也已经正常用了两年多了。

怎么能怪 TestNG 呢

楼上的兄弟们，他那个时间是在每次测试之前重新赋值了的，@BeforeMethod 干的；但是他的测试方法是个多线程运行的，一组线程每个来运行测试前都执行一遍赋值，个个去改那个变量由不做任何同步，并发下能一致才见了鬼了

不是，他那问题是个典型并发问题。。。

因为电报不会扫描硬盘吧

楼上 #44, #45, #46 的兄弟已经说的很清楚了；单元测试还是应该写的，项目忙，总有不忙的时候，自己慢慢写；如果先是写的代码后来补的测试，通常写单元测试时候你会发现大量的不方便和麻烦的地方；而这正是单元测试一个重要的意义所在，通过单元测试来重构和改善自己的代码；让代码设计更合理，更解耦，更容易测试；写久了之后再写代码时候即使不写测试，也会让你思维有很大的转变，在写之前就会考虑这些代码别人要怎么用，怎么测；这也是 TDD 的意义。

从我的经验来看，愿意写单元测试和会写单元测试的工程师，最终的代码设计和质量明显会高别人一节；所以我建议，楼主能多写单元测试就多写单元测试，而且就个人的经验来讲，通过写单测去提升代码的设计能力，比去空学各种设计模式和开源项目更有效。

原来这么多才通网的兄弟

我也是装的 smart youtube，用着没问题

反正我听的貌似都有，老婆听粤语和古典，也基本上都有；
什么抖音上的那些网络神曲没有是真的

你应该反问，为什么会有这样的发布流程和结果。 这种结果应该不是为了 AB 测试

真心的不用聊天软件，直接动车过去喊晚上出来喝酒