unit-testing - 自测系统

标签 unit-testing language-agnostic

我有一个想法,正在与一些同事一起考虑。我们谁也不知道它目前是否存在。

基本前提是拥有一个具有 100% 正常运行时间但可以动态提高效率的系统。

Here is the scenario:

* So we hash out a system quickly to a specified set of interfaces, it has zero optimizations, yet we are confident that it is 100% stable though (dubious, but for the sake of this scenario please play along)

* We then profile the original classes, and start to program replacements for the bottlenecks.

* The original and the replacement are initiated simultaneously and synchronized.

* An original is allowed to run to completion: if a replacement hasn´t completed it is vetoed by the system as a replacement for the original.

* A replacement must always return the same value as the original, for a specified number of times, and for a specific range of values, before it is adopted as a replacement for the original.

* If exception occurs after a replacement is adopted, the system automatically tries the same operation with a class which was superseded by it.


你在实践中见过类似的概念吗? 请批评...

Below are comments written after the initial question in regards to posts:

* The system demonstrates a Darwinian approach to system evolution.

* The original and replacement would run in parallel not in series.

* Race-conditions are an inherent issue to multi-threaded apps and I acknowledge them.

最佳答案

我认为这个想法是一场有趣的理论辩论,但由于以下原因不太实用:

  1. 要确保新版本的代码运行良好,您需要进行出色的自动测试,这是一个很难实现的目标,也是许多公司未能开发的目标。只有在此类自动测试到位后,您才能继续实现该系统。
  2. 这个系统的全部意义在于性能调整,即 - 代码的特定版本被替换为性能上取代它的版本。对于当今的大多数应用程序,性能是次要的。意思是,大多数应用程序的整体性能是足够的 - 想想看,你可能很少发现自己提示“这个应用程序非常慢”,相反你通常会发现自己提示缺乏特定功能、稳定性问题、UI 问题等. 即使您确实提示运行缓慢,这通常是系统整体运行缓慢,而不仅仅是特定应用程序(当然也有异常(exception))。
  3. 对于性能是一个大问题的应用程序或模块,改进它们的方法通常是识别瓶颈,编写新版本并首先独立于系统进行测试,使用某种基准测试。当然,对整个应用程序的新版本进行基准测试也是必要的,但总的来说,我认为这个过程只会发生非常少的次数(遵循 20%-80% 的规则)。在这些情况下,“手动”执行此过程可能比所描述的系统更容易且更具成本效益。
  4. 当您添加功能、修复与性能无关的错误等时会发生什么?您不会从该系统中获得任何好处。
  5. 同时运行这两个版本来比较它们的性能所遇到的问题远比您想象的要多 - 不仅您可能会遇到竞争条件,而且如果输入不是合适的基准,您可能会得到错误的结果(例如,如果您获得大量小数据包,即 90% 的时间输入是大数据包)。此外,这可能是不可能的(例如,如果实际代码更改了数据,则不能同时运行它们)。

这听起来很有用并且实际上是“必须”的唯一“环境”是一个“遗传”系统,它可以自行生成新版本的代码,但这是一个完全不同的故事,并没有真正广泛适用......

关于unit-testing - 自测系统,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/60478/

相关文章:

c++ - 在windows中使用gcc+gtest+mockcpp,mock根本不起作用

unit-testing - VS2012 - 添加测试丢失?

c# - 更改生成的单元测试文件的目录

math - float 学坏了吗?

web-services - 现实生活中的 Atom 发布协议(protocol)

Angular2 单元测试 - 未触发 MdCheckbox 中的更改事件

c# - Directory.GetFiles 的单元测试条件

language-agnostic - 错误处理。一个程序应该怎么做?

oop - 减少构造函数的参数数量

language-agnostic - 适用于多个编辑器的语法高亮工具/语言