我发现我的许多计算科学编程都有标准测试框架未涵盖的测试要求:
计算时间测试
- 确保算法不会变慢。我可以做类似
的事情,
assureSmallerEqual(RuntimeWrapper(algorithm),53)
但我希望在我研究算法时不断减少 53 秒的阈值,即类似assureSmallerEqual(RuntimeWrapper(algorithm),'previousbest+noisetolerance')
- 确保算法不会变慢。我可以做类似
的事情,
性能测试
- 确保先前找到解析解的良好近似的算法仍然可以找到至少相同或更好的解。同样,这可以通过标准集成测试来模拟,但我希望容差随着算法变得越来越好而不断缩小。考虑替换
assureAlmostEqual(foo(),1,places=3)
为assureAlmostEqual(foo(),1,places='previousbest')
- 确保先前找到解析解的良好近似的算法仍然可以找到至少相同或更好的解。同样,这可以通过标准集成测试来模拟,但我希望容差随着算法变得越来越好而不断缩小。考虑替换
物理要求测试
- 确保算法不会突然需要更多内存/硬盘空间。与1非常相似。
抽象需求测试
- 为了确保在二次近似上表现良好的算法不会突然需要三次近似,或者在时间步长 0.1 上表现良好的算法不会突然需要 0.01 来保持稳定性。同样,这些可以通过标准集成测试来模拟,但目标是记住实现某个目标的最小需求参数是什么,因此这需要大量手动更新。例如,如果
foo(10)
之前没有抛出异常,我希望框架确保foo(10)
仍然有效,并且如果现在有效,也可以尝试foo(9)
(在这种情况下,所有未来的测试都将确保foo(9)
仍然有效)。
- 为了确保在二次近似上表现良好的算法不会突然需要三次近似,或者在时间步长 0.1 上表现良好的算法不会突然需要 0.01 来保持稳定性。同样,这些可以通过标准集成测试来模拟,但目标是记住实现某个目标的最小需求参数是什么,因此这需要大量手动更新。例如,如果
有人可能会争辩说,我所要求的并不是在单元/集成测试的意义上描述测试,因为例如,增加运行时间可能是可以接受的,以换取其他改进。
然而,在实践中,我知道如果我有上面的测试功能,我会节省很多调试时间,因为在 95% 的情况下,需求和性能会因为我引入的错误而出错。事实上,我知道一个事实,如果严格应用上述测试,我可以轻松避免使用外部数值软件库发现的许多错误(在检查我自己的代码上浪费了很多时间)。
附言
类似名称的问题https://stackoverflow.com/questions/34982863/framework-for-regression-testing-of-numerical-code不是重复的,因为它描述了使用标准回归测试框架更容易实现的功能。
单元测试和测试驱动开发的问题策略要求提供策略,而不是帮助实现它们的框架(在我看来,它要求/在答案中提供的策略与我在这里描述的不同)。