随着越来越多的努力将软件分成独立的层并使用动态发现和依赖注入将它们分离，确定系统中哪个“层”导致“应用程序”的系统级故障变得更加困难”
单元测试有助于确保构成图层的所有“模块”按预期工作。但是单元测试的编写方式是每个“模块”都是通过使用诸如存根和模拟等技术来隔离的。
考虑以下简单示例：
L1。数据库 - ＆gt; L2。数据库层 - ＆gt; L3。 Windows服务 - ＆gt; L4。客户申请
例如，如果数据库引擎关闭，则系统将无法正常运行。很难判断数据库引擎是否真的关闭或数据库层（L2）代码中是否存在错误。要检查，您必须启动某种数据库管理工具来检查数据库引擎是否正在运行。
我们想要实现的是一个开发人员工具，只要系统“出现问题”就可以启动，并且该工具将“查询”每个层的“完整性”或“诊断”数据。该工具将提供软件层列表及其“完整性状态”。然后就可以说，正确地说，层X是导致问题的原因（即数据库引擎已关闭）。
当然，每一层都有责任提供自己的“诊断方法”，工具可以查询。
我想我们在这里尝试实现的是某种“集成测试”框架或类似的东西，可以在运行时使用（不像编译单元测试那样编译/构建时）。灵感来自具有自己的“车载诊断”的物理设备，如汽车。软件世界中的一个很好的例子是每次打开计算机时都会运行开机自检。
有没有人见过或听过这样的话？任何建议或指示肯定会有很大帮助！
答案 0 :(得分：0)
您可以拥有一个通用接口，每个层都将实现为WCF服务。这样您就可以连接到每个图层并进行诊断。提供此诊断可能很有用，但如果您想在任何地方（每一层）实施它，那么另一件事可能会失败 - 您将如何诊断？您的系统会使用WCF服务，因为它需要大量维护并且不太稳定。此外，它还需要大量工作才能实施。
我建议的替代方案是建立一个良好的测井系统。最小化是让所有catch部分中的每个模块都记录错误，但我建议更多，特别是出于调试目的。我建议使用免费且非常灵活的Log4Net。在不需要时不进行日志记录是有效的，这意味着您可以将日志记录级别设置为高，即使在生产代码中也不会影响性能。您可以通过更改配置文件中的设置来更改运行时的日志记录级别。我经常使用Log4Net，效果很好。
完成代码记录后，您可以配置Log4Net，以便所有日志都进入中央数据库。然后，您将有一个地方可以相对容易地诊断正在发生的事情，发生了什么故障，在哪里以及什么是例外或消息。您甚至可以设置在出现问题时发送的电子邮件。