单元测试网络异步代码的最佳实践是什么？我正在尝试做/学习tdd
我目前正在计划图书馆的这一部分，但原则上： 这是一个ssh客户端库。我希望它是异步的。实际上，Ssh连接过程非常复杂。我的connect方法会以原子方式设置一些连接状态变量，然后使用某种任务执行器来安排连接任务。连接需要连接到服务器，通过发送和接收ssh协议版本和东西来引入，然后完成密钥交换过程，这本身被分成几个案例，因为几乎没有密钥交换算法，每个都需要交换不同的数据包。 / p>
虽然我听说我应该测试公共api，并通过测试使用它的公共方法测试私有方法，但在这种情况下似乎很难，因为任务非常复杂，并且可能更容易伪造一部分协商与整个连接/协商，只是为了检查连接方法的每个可能结果，包括每个密钥交换算法的结果。
将较大的连接任务拆分为较小的连接任务是否是一个很好的理由，即使它们不是公开可供用户使用，并且一次测试每个单独的连接阶段而不是整个连接方法？它是以某种方式打破最佳实践，或以不同方式如何做到这一点？例如，它是否测试实现细节？
答案 0 :(得分：1)
单元测试网络异步代码的最佳实践是什么？我正在尝试做/学习tdd
您需要阅读的参考文献是Growing Object Oriented Software，由Freeman和Price撰写。该文本详细介绍了如何使用测试来开发异步网络拍卖客户端。
正如作者所描述的那样，在开始填写其他细节之前，该过程需要进行大量工作，以便首先进行初始端到端测试并先运行。
当然，这不是唯一的方法。
虽然我听说我应该测试公共api，并通过测试使用它的公共方法测试私有方法
是的，还有......
在这种情况下似乎很难，因为任务非常复杂，并且可能更容易伪造一部分谈判而不是整个连接/协商，只是为了检查连接方法的每个可能结果，包括每个键的结果交换算法。
经常发生的是，复杂的解决方案可以分解为模块，每个模块都包含自己的公共API＆＃34; - 见Parnas的On the Criteria to be Used in Decomposing Systems into Modules。然后，您可以单独测试模块。
例如，通常情况下，您的代码可以组织成两堆;一个内部功能核心，然后是一个与boundary of your system交互的命令性shell。作为一项规则，功能核心比命令式shell更容易测试，因此努力寻找一个简单明了没有缺陷的shell。＆＃34;
那么public api的定义是什么？
粗略地说：在实施范围之外可以获得的可供性。
换句话说，它们是模块的一部分，无需重写调用模块的代码即可进行更改。
在这种情况下，我可能会将连接过程分为子任务，如连接，ssh介绍和密钥交换。并单独测试单个子任务。此外，我将独立于特定的密钥交换算法实现来测试密钥交换支持。测试每个部分的要求是不同的，只有第一部分需要模拟套接字。
您可能还想看看Cory Benfield的演讲Building Protocol Libraries the Right Way。
不确定是否可以。
如果你没有做到这一点，TDD警察就不会来你家门了＃14;对＃34;在最坏的情况下，他们会给你写a nasty note。