SQLite声称测试代码比生产测试代码多679倍。 http://www.sqlite.org/testing.html
有谁知道怎么可能？他们是否自动生成任何测试代码？这些“45678.3 KSLOC”测试代码的主要部分是什么？
答案 0 :(得分：4)
“有谁知道怎么可能？”
“有可能”拥有679倍的测试代码，因为可以通过多种不同的方式使用单个功能。只考虑一个带有两个参数的函数。我可以为那个测试边界条件和许多其他条件组合的函数生成很多测试代码。当您考虑测试的设置/拆除时，那里还有其他代码。根据他们的测试框架，这种开销可能会显着增加测试中的代码量。
它真正归结为一个软件可以以多种不同方式使用的事实，这意味着你有许多不同的场景需要测试。这就是美丽的优雅的软件，一个简单的程序可以应用于众多场景，但这与使验证和测试软件如此具有挑战性相同。
答案 1 :(得分：3)
如果开发人员花在编写测试代码上的时间是编写生产代码所花费的时间的679倍，那么这可能是可能的。试想一下：如果他们选择了339倍的测试代码，那么他们可能已经拥有两个整个数据库引擎，每个引擎仍然有大量的测试覆盖率。
我曾经看过一位开发人员试图通过告知他们编写的测试代码是生产代码的5倍，试图安抚一位愤怒的客户。如果您能想象，客户不安抚。至少我认为5X报道不再是极端的。
答案 2 :(得分：1)
它使用Tcl为测试框架提供动力，因此编写测试比编写实现要容易得多。这鼓励彻底的测试，这是你想要的数据库，是吗？此外，这些测试中相当一部分是专有的，旨在在嵌入式环境中进行测试;我想一些企业用户（或用户）为此类事情付费。也很可能多次测试相同的功能。
答案 3 :(得分：1)
查看第3.1节（OOM）：
OOM测试由以下人员完成 模拟OOM错误。 SQLite允许 替代的申请 替代malloc（）实现 使用 sqlite3_config（SQLITE_CONFIG_MALLOC，...） 接口。 TCL和TH3测试 安全带都有能力 插入修改后的版本 malloc（）可以操纵失败 经过一定数量的分配。 可以设置这些检测的malloc 只失败一次，然后开始 再次工作，或继续失败 第一次失败后。 OOM测试是 在一个循环中完成。在第一次迭代 循环，仪表化malloc 在第一次被操纵失败 分配。然后是一些SQLite操作 执行并进行检查 确保SQLite处理OOM错误 正确。然后是失败的时间 仪表化的malloc上的计数器是 增加一，测试是 重复。循环一直持续到 整个操作运行完成 没有遇到模拟 OOM失败。像这样的测试运行 两次，一次用仪表 malloc设置为仅失败一次，并且 再次使用仪表化的malloc集 在第一次之后不断失败 故障。
请注意，第7节明确规定了由gcov确定的100％核心覆盖率。我同意Donal Fellows，测试框架主要负责测试覆盖范围，超出了调用图的建议范围。看到malloc（）进入 nn 次并为其编写测试，而不是写几十个测试来模拟malloc（）可能失败的环境，这是另一回事。
是的，由此产生的覆盖范围是一种勤奋的工件，但选择一种能够实现这种勤奋的测试框架也是如此。
最后，重申显而易见的，malloc()只需要一个空指针。这表明围绕它编写的测试是经过深思熟虑的设计，而不是自动生成的。