上次跟妳讲的几个问题，我把总结成文档了，妳有空思考一下。
库底层 api 的实现决定了库的使用方法。
testcase 需要模拟用户使用。
若干因素会影响到使用者
- 同步/异步编程模型。
已实现同步，现有所有代码基于同步编程模型开发，不需要注册回调函数。异步方式的测试代码其实和同步的大体相同，只不过调用、使用方式有所区别。没必要写两份差不多的代码。
妳思考一下，如何通过采用统一的 testcase，测试async/sync的api
若干因素会影响到 testcase
- 测试逻辑
比如如下是针对 get 的单元测试，如果它通过，说明 get 命令确实可用(关于 get：https://redis.io/commands/get)。
test("get"); {
c.set(foo, bar);
ASSERT_EQUAL(c.get(foo), bar);
}
比如如下是针对 set 的单元测试，如果它通过，说明 set 命令确实可用(关于 set：https://redis.io/commands/set)。
test("set"); {
c.set(foo, bar);
ASSERT_EQUAL(c.get(foo), bar);
}
但是，
get 的 UT 通过的前提条件是 “set 确实能设置一个 key 的值”(即 set 的 UT 通过)。
set 的 UT 通过的前提条件是 “get 确实能取得一个 key 的值”(即 get 的 UT 通过)。
由此可以看出，各个api的UT之间是存在依赖关系的，无法保证这些测试用例从逻辑上完全正确。
以上是实际的一种情况。
如下抽象一下：
logic dependency:
T(A) -> T(B)
T(B) -> T(C)
testcase:
TestA(...);
TestB(...);
TestC(...);
如果
B 的 UT 通过的前提是 A 的 UT 通过。
C 的 UT 通过的前提是 B 的 UT 通过。
就可以通过测试函数的调用顺序解决问题，A 放在 B 之前，如果 A 不通过，则直接退出，不会执行到 B，如此等等。。如果程序执行完，则说明 A, B, C 都通过了。
现在的代码有些是使用这种方法写的，但是 api 之间的耦合多了，就没法这么写了。
妳思考一下，怎么保证 testcase 从逻辑上是完备的。
- api太多
如果这些 testcase 全部都手动写，确实可以实现测试需求，但是随着 api 的变化，会导致 testcase 每次都需要改动。其实，testcase 是由api实现决定并由其预期的，所以理论上是能做到自动生成。这样作为库的开发者，只需要实现底层功能和生成 testcase 的代码即可，可做到“只改实现和预期，不改 testcase”。
妳思考一下，如何做到从预期出发，最终不需要写 testcase，让程序自己生成 testcase。
