如果创建了一个包含静态方法签名的接口，我将有办法测试依赖于这些静态方法的类。
但是，我如何测试实现接口并包装这些静态方法的具体包装类？
我是否只是不测试具体的包装类？
似乎包装静态方法只是将问题转移到其他地方。我还有一些类，包装类，很难测试。
答案 0 :(得分：3)
你走在正确的轨道上，但是你没有把问题转移到其他地方 - 你正在隔离它以防止问题在整个代码库和其他测试中泄漏。如果你对包装行为做出错误的假设或者忽略了证明这些假设，我只会将此视为一个问题。需要进行一些测试，但难度不同。您选择测试这些假设的距离将是您需要做出的权衡。
对于某些情况，可以测试包装器，但需要您可以控制的物理依赖项。例如，修改文件的静态方法将需要您花时间设置文件系统，或者从Web服务器下载文件的帮助程序类。我喜欢将这些测试视为“集成测试”而不是“单元测试”，因为它们依赖于它们的依赖性而不是孤立地运行。由于这些测试可能需要更长的时间来执行标准测试，因此您可能希望将它们排除在外，并且比较快的单元测试更少地运行它们。
对于其他方案，您可能无法在不费力的情况下编写测试。例如，您可能已经在单独的窗口中包含显示对话框的逻辑 - 在代码中测试此逻辑将会很多工作，但启动应用程序并验证它是否有效可能就足够了。你会受到代码覆盖的打击，但对我来说这是一个可以接受的权衡。
关键的挑战是理解包装行为的假设 - 例如，如果Web请求格式错误或网络连接丢失，从远程服务器抛出什么类型的异常？如果您没有正确捕获这些假设，那么这些错误将会冒泡到代码的其他区域。