如果测试脚本需要被测试的话，那么用来测试测试脚本的脚本需不需要被测试？

[Tetsuchou]

（我不是在黑 Golang 或者 TDD 或者任何自动化测试相关的东西）

[hxd]

@codermagefox 三权 /多权分立，互相监督

[luoway]

给测试脚本写测试本就过分了，测试脚本不会影响业务代码，没必要写测试。
如果是为了让测试代码也趋近测试正确，那么就会陷入这种循环。
而且这种循环是没有终点的，是人就会犯错，给测试脚本写测试并不能避免犯错。

[carlclone]

细分到一个合适的点就够了

[scnace]

哦 知道你不是在黑 Go 了

[warcraft1236]

所以很简单，测试脚本的逻辑足够简单，这样就基本上可以保证测试脚本出 bug 的概率很小很小。这个时候就可以认为测试脚本没有 bug

[night98]

测试脚本只测试，不会再写脚本去测，哈哈。

[msg7086]

自动化测试主要有两个作用。
1. 找出开发过程中新代码引入的问题。
2. 找出升级和重构过程中引入的问题。
软件测试也没有银弹。自动化测试只是用很小的代价带来很大的收益的手段。
达到百分之百正确的代码……连行星探测器固件都不见得能自称百分之百正确的。

[likuku]

所以才有多备份冗余和相互表决仲裁机制...参考：

F-16 战隼战斗机 - 电传操纵 维基百科，自由的百科全书 : https://zh.wikipedia.org/wiki/F-16%E6%88%B0%E9%9A%BC%E6%88%B0%E9%AC%A5%E6%A9%9F#%E7%B7%9A%E5%82%B3%E9%A3%9B%E6%8E%A7

"因此尽管 F-16 是负稳定，但仍使 F-16 可以飞行。而为减少因电脑故障所产生的错误，F-16 在一般时间仅启动 3 部电脑进行飞控计算作业，第四部为备份电脑，并在飞控程式中建立一套表决系统，当某一部电脑所计算的结果与另两部电脑不同时，表决系统就立即启动，跳过并关闭计算结果不同的电脑，同时命令第四部备用电脑启动，以确保操控安全性。"

[asj]

TDD 流程里写了测试还没实现的时候，非要 2b 兮兮的先运行一遍测试失败，再开始实现。就是为了简单的测试测试用例本身。
写了一段代码后原来失败的测试通过了。说明这个测试自己是和这段代码行为有关系的。
当然未必严谨，但是基本够用了。

[yuriko]

@chaleaochexist not a bug 不是开发说了算的，要产品签字同意

[chaleaochexist]

@yuriko 因为测试脚本产生的 bug 需要产品签字同意.

行吧,每家公司可能规定不一样.

不再继续讨论此话题.