java如何测试复杂的异步网络代码并遵循tdd

Question

单元测试网络异步代码的最佳实践是什么？我正在努力做/学tdd

我目前正在规划图书馆的这一部分，但原则上： 这是一个ssh客户端库。我希望它是异步的。Ssh连接过程实际上非常复杂。我的connect方法将以原子方式设置一些连接状态变量，然后使用某种任务执行器来调度连接任务。连接需要连接到服务器，通过发送和接收ssh协议版本和内容引入，然后完成密钥交换过程，该过程本身分为几个案例，因为很少有密钥交换算法需要交换不同的数据包

虽然我听说我应该测试公共api，并通过测试使用它的公共方法来测试私有方法，但在这种情况下似乎很困难，因为任务相当复杂，可能更容易伪造部分协商而不是整个连接/协商，只需检查连接方法的每个可能结果，包括每个密钥交换算法的结果

将较大的连接任务拆分为较小的连接任务（即使这些任务对用户不公开），并测试每个单独的连接阶段，而不是一次测试整个连接方法，这是一个很好的理由吗？它是否以某种方式打破了最佳实践，或者如何以不同的方式做到这一点？例如，它是否正在测试实现细节

Answer 1

What would be the best practices for unit testing networked asynchronous code? I am trying to do/learn tdd

你需要阅读的参考资料是Growing Object Oriented Software，作者是弗里曼和普莱斯。这篇文章包含了如何使用测试开发异步网络拍卖客户端的详细介绍

正如作者所描述的，在开始填写其他细节之前，这个过程会先加载大量的工作，以获得初始的端到端测试并运行

当然，这不是唯一的方法

Although I heard that I should test public api, and test private methods by testing public methods that use it

是的，而且

in this case it seems difficult, as the task is quite complex and it is probably easier to fake only parts of a negotiation versus the whole connection/negotiation, just to check each possible result of a connect method including results of every key exchange algorithm.

经常发生的事情是，一个复杂的解决方案可以分解成模块，每个模块都包含自己的“公共API”，请参见Parnas的On the Criteria to be Used in Decomposing Systems into Modules。然后可以单独测试模块

例如，结果往往是，你的代码可以被组织成两堆；一个内部的功能核心，然后是一个与boundary of your system交互的命令外壳

一般来说，功能内核比命令式shell更容易测试，所以要争取一个“简单到明显没有缺陷”的shell

so what is the definition of public api?

大概是：在实现范围之外可以访问的启示

换句话说，它们是模块的组成部分，如果不重写调用模块的代码，就无法更改

in this case I would probably split connection process into subtasks, like connection, ssh introduction and key exchange. And test individual subtasks in isolation. Also I would test key exchange support in isolation from specific key exchange algorithm implementations. Requirements for testing each of those parts are different, and only the first requires mocking a socket.

你可能还想看看科里·本菲尔德的演讲Building Protocol Libraries the Right Way

Not sure if that is okay or not.

如果你做得不“正确”，TDD警察不会来踢你的门。最坏的情况下，他们会给你写信