提供了分组的装饰器实现

[wureny]

#32

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (8c6eedc) 97.94% compared to head (04bc9da) 98.04%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #33      +/-   ##
==========================================
+ Coverage   97.94%   98.04%   +0.10%     
==========================================
  Files           4        6       +2     
  Lines         632      665      +33     
==========================================
+ Hits          619      652      +33     
  Misses          9        9              
  Partials        4        4              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[flycash]

这边操作有点不太对。实际上你只需要实现一个 namespace cache 的装饰器，然后随便搞个测试就可以。

也就是说，memory 和 redis 那两个部分呢是不需要修改的。

道理也很简单，如果用户要使用 namespace 的特性，他们自己手动创建 memory 或者 redis 的实现，而后自己来组装。

你可以预期，我们将来会有很多的装饰器，所以不可能每一个装饰器都改过去 memory 那些地方。

在测试的时候，你可以考虑生成一个 mock 的实现，然后里面这个mock 实现来构建 namespaceCache。在测试里面重点检测 namespace 是否真的正确处理了 key 就可以。

[wureny]

已更新

[flycash]

1. 所有的方法都必须要测试一遍，你需要检查每一个方法都正确处理了 key。
2. 把 mock 生成的文件重命名为 mock_cache_test.go，或者你重新生成，然后指定这个文件名。
3. 按照 table driven 的形态来编写测试

[flycash]

我的意思是=。=，有一个 cache 的 mock 代码，放到这个文件里面。

另外 namespace 的测试，放到另外一个文件。

• mock_cache_test.go
• namespace_cache.go
• namespace_cache_test.go

[flycash]

你这个可以和前面的合并在一起。这样设计测试用例：

testCases := []struct{
    name string
    keys []string
    mock func(ctrl *gomock.Controller) Cache
    wantCnt int64
    wantError
}

然后在测试代码里面：

c := NamespaceCache{
    Cache: tc.mock(ctrl)
}
c.Delete(ctx, tc.keys...)

整体来说，我看到你这里是遵循了 Goland IDE 生成的测试模板。后面其实犯不着，因为它的模板很难用。