我的基类使用负责审计的java库。该库使用生成器模式从我的 Java 项目中检索对象以进行审核操作(通过自行创建键插入到多个表中。)
该库使用 com.google.common.cache管理缓存值。即字符串和值。
LoadingCache<String, Long>
示例我的项目如何使用库
auditOperation = LibraryAuditBuilder.builder()
//some param
.build()
LibraryAuditingService.process(auditOperation);
我的基础应用程序和库在 Oracle 数据库上运行，我的单元测试使用 HSQL 数据库。给出 @Before 中所有必需的脚本我想对我的代码的执行进行单元测试。
@Before方法
@Before
public void setUp() throws Exception {
MockitoAnnotations.initMocks(this);
//create db scrips and other declarations
}
到目前为止我已经尝试了两种方法
1) 创建LoadingCache并将示例值放入其中，以便 UnitTest 可以在稍后的执行中使用它。
longLoadingCache.put("4028eeb0-1d2d-daba-011d-2e36e4b2110e",(long)203);
longLoadingCache.put("4028ee14-24b4-5221-0124-b47bbb1d1232",(long)102);
2) @Mock LoadingCache 的对象以及稍后在测试中使用的值
when(longLoadingCache.get("4028eeb0-1d2d-daba-011d-2e36e4b2110e")).thenReturn((long)203);
when(longLoadingCache.get("4028ee14-24b4-5221-0124-b47bbb1d1232")).thenReturn((long)102);
上述两种方法的当前输出
- com.google.common.cache.CacheLoader$InvalidCacheLoadException: CacheLoader returned null for key 4028ee14-24b4-5221-0124-b47bbb1d1232.
所以我的问题是，如何传递/模拟 Cache 的值，以便 UnitTests 不必在 Library 类中查找值。
最佳答案
考虑创建您自己的外观 bean 来包装第 3 方库(例如 AuditProcessor)。当使用 @Autowire 或 @Inject 注入(inject)外观时，您可以轻松地在测试代码中模拟它，并检查您的包装外观(读取:库)是否已正确使用。如果您不信任该库，您可以在没有 HSQL 的隔离环境中对包装外观和所有极端情况进行单元测试。如果您想要更多控制，您可以引入一个接口(interface)(例如 IAuditProcessor)并创建一个虚拟实现，该实现将在使用 Spring 配置文件的测试中@Autowired。
总结一下:
- 基于 HSQL 的测试应测试外观是否按预期调用且参数正确
- 应该在没有 HSQL/Spring 上下文的独立测试用例中单独测试极端情况/缓存
关于java - 如何使用 Mockito 在单元测试中模拟 LocalCache，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/55972811/