[design draft] testcase for redis-cpp

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

库底层 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。