客户端-服务器应用程序上的 TDD

发布于 2024-08-22 13:43:10 字数 107 浏览 4 评论 0原文

目前我正在创建一个服务器应用程序来接收特定于协议的消息。我需要创建测试以确保我已正确实现协议。这是某种集成测试吗?如果是的话,我可以使用单元测试工具进行集成测试吗?最后,创建此类测试的最佳方法是什么?

Currently I'm creating a server application to receive protocol-specific messages. I need to create tests to ensure that I've implemented the protocol correctly. Is this some kind of integration testing? If positive, can I make an integration testing with unit testing tools? And finally, what is the best way to create these kind of tests?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

雾里花 2024-08-29 13:43:10

如果您知道正确的响应是什么,那么我会这样做:将

负责处理协议逻辑的类与处理连接机制的代码分开。

一次编写一个测试,为一组给定的输入消息指定正确的响应。

实施这些行为。

例如,如果应该用“howdy”消息来响应“hello”消息,则您的测试可能如下所示:

Mock<IProtocolOut> outbound = new Mock<IProtocolOut>();
MyProtocolHandler handler = new MyProtocolHandler(outbound); // assuming that the handler takes the outbound receiver as a parameter.
outbound.Expect(o=>o.HowdyMessage()); // we expect to get a HowdyMessage back
handler.HelloMessage(); // 'fake' a HelloMessage into the handler
outbound.VerifyAll(); // assert that the 'howdy' message was sent.

在这种情况下,所有模拟所做的就是断言已进行某些调用。这也可以通过手动滚动类来进行验证来完成 - 模拟没有什么神奇之处,它们只是使进行此类验证变得更容易。

如果您有一个支持 Arrange/Act/Assert 的模拟库,它看起来更像是这样:

Mock<IProtocolOut> outbound = new Mock<IProtocolOut>();
MyProtocolHandler handler = new MyProtocolHandler(outbound); // assuming that the handler takes the outbound receiver as a parameter.
handler.HelloMessage(); // fake the message being sent
outbound.AssertWasCalled(o=>o.HowdyMessage());

当然,协议的接口不必与消息一起强类型化。您还可以执行与此类似的操作:(

Mock<IProtocolOut> outbound = new Mock<IProtocolOut>();
MyProtocolHandler handler = new MyProtocolHandler(outbound); // assuming that the handler takes the outbound receiver as a parameter.
handler..ReceiveMessage("hello"); // fake the message being sent
outbound.AssertWasCalled(o=>o.ReceiveMessage("howdy"));

编辑以澄清测试范围)

这些都不需要“实际”连接。他们仅测试处理协议的逻辑方面,并假设逻辑协议处理和连接管理之间存在分离。

If you know what the correct responses are, then here's what I'd do:

Separate the class responsible for the logic of handling the protocol from the code dealing with the mechanics of the connection.

Write tests, one at a time, specifying the correct response for a given set of input messages.

Implement those behaviors.

For instance, if a "hello" message is supposed to be responded to with a "howdy" message, your test might look something like this:

Mock<IProtocolOut> outbound = new Mock<IProtocolOut>();
MyProtocolHandler handler = new MyProtocolHandler(outbound); // assuming that the handler takes the outbound receiver as a parameter.
outbound.Expect(o=>o.HowdyMessage()); // we expect to get a HowdyMessage back
handler.HelloMessage(); // 'fake' a HelloMessage into the handler
outbound.VerifyAll(); // assert that the 'howdy' message was sent.

All the mock does in this case is assert that certain calls were made. This can be done by hand-rolling classes to do the verification as well - there's nothing magic about mocks, they just make it easier to do this type of verification.

If you have a mock library that supports Arrange/Act/Assert, it'd look something more like this:

Mock<IProtocolOut> outbound = new Mock<IProtocolOut>();
MyProtocolHandler handler = new MyProtocolHandler(outbound); // assuming that the handler takes the outbound receiver as a parameter.
handler.HelloMessage(); // fake the message being sent
outbound.AssertWasCalled(o=>o.HowdyMessage());

The interfaces for the protocols don't have to be strongly typed with the messages, of course. You could also do something similar to this:

Mock<IProtocolOut> outbound = new Mock<IProtocolOut>();
MyProtocolHandler handler = new MyProtocolHandler(outbound); // assuming that the handler takes the outbound receiver as a parameter.
handler..ReceiveMessage("hello"); // fake the message being sent
outbound.AssertWasCalled(o=>o.ReceiveMessage("howdy"));

(edit for clarification of test scope)

None of these require an 'actual' connection. They test the logical aspects of handling the protocol only, and presume that you have a split between the logical protocol handling, and the connection management.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文