[design draft] testcase for your library

上次跟妳讲的几个问题，我把总结成文档了，妳有空思考一下。

库底层 api 的实现决定了库的使用方法。
testcase 需要模拟用户使用。

若干因素会影响到使用者

1. 同步/异步编程模型。
   已实现同步，现有所有代码基于同步编程模型开发，不需要注册回调函数。异步方式的测试代码其实和同步的大体相同，只不过调用、使用方式有所区别。没必要写两份差不多的代码。

妳思考一下，如何通过采用统一的 testcase，测试async/sync的api

若干因素会影响到 testcase

1. 测试逻辑
   比如如下是针对 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 从逻辑上是完备的。

2. api太多
   如果这些 testcase 全部都手动写，确实可以实现测试需求，但是随着 api 的变化，会导致 testcase 每次都需要改动。其实，testcase 是由api实现决定并由其预期的，所以理论上是能做到自动生成。这样作为库的开发者，只需要实现底层功能和生成 testcase 的代码即可，可做到“只改实现和预期，不改 testcase”。
   妳思考一下，如何做到从预期出发，最终不需要写 testcase，让程序自己生成 testcase。