我对JUnit测试结构存在架构困境。
我的测试类的流程测试从大文件加载字典。由于内存不足，找不到文件，文件结构错误等原因，该类可能会失败。
第一方面，在特定订单上运行测试是很有意义的：检查内存，然后检查文件是否存在，然后检查其结构。这将非常有用，因为如果我们没有足够的内存，相应的测试将失败并提供有意义的输出，而不是神秘的OutOfMemoryException。而且，我不必一遍又一遍地重复阅读文件的耗时过程。
另一方面，测试应该是孤立的，自包含的实体。
如何设计测试套件的任何想法？
答案 0 :(得分：3)
您所描述的是集成测试，而不是单元测试。单元测试（理想情况下）不应该依赖于文件系统，可用内存量等。
您应该在字典中使用可管理的数据量设置单元测试（最好从测试夹具代码中的字符串（流）初始化，而不是从外部文件初始化）。这样，您可以针对每个单元测试用例独立地重新初始化您的测试夹具，并测试您需要的关于字典结构的任何细节。
当然，您还应该创建单独的高级集成测试，以验证您的系统在现实环境中是否按预期工作。如果将它们与真正的单元测试分开，您可以在任何代码更改后通过JUnit运行（廉价和快速）单元测试，并且通过其他方式运行更昂贵的集成测试，只是更少，取决于它们需要多长时间，例如每晚一次。您也可以选择设置集成环境一次，并以明确定义的顺序运行集成测试（通过JUnit之外的其他方式，例如shell /批处理脚本），或者为每个测试用例重新加载字典文件，如延长执行时间在夜间构建期间可能无关紧要。
答案 1 :(得分：1)
添加到佩特所说的内容：
OOME 单元测试不会依赖于实际内存不足。相反，当负载代码抛出OOME时，对文件加载的任何调用都应该做出适当的反应。这就是嘲笑/等等。用于 - 模拟正在测试的行为 之外的行为。 （对于丢失的文件/文件结构错误也是如此。）
IMO加载一个对JVM配置来说太大的文件在实际加载文件的代码中进行测试并不是一件有用的事情 - 只要对文件加载的任何调用都适当地处理OOME - 至少不是在单元测试中。
如果代码加载需要一些行为验证，当文件太大时我会考虑删除文件加载部分而强制一个OOME，而不是实际加载一个巨大的文件，只是为了省时间。重申他的观点，实际的物理行为可以转移到集成测试，比如在你自己的TDD心跳之外的CI服务器上运行。