如何使用自定义协议测试驱动网络应用程序?

发布于 2024-08-10 23:56:51 字数 463 浏览 6 评论 0原文

我目前正在为学校项目开发两个 Java 网络应用程序。一种通过 TCP,另一种通过 UDP。在这两种情况下,我都必须实现简单的自定义协议。

尽管我非常努力,我找不到正确测试此类应用程序的方法,或者通过测试优先开发更好地进行开发

如果我有一个客户端,并且想要进行真正的测试,而不需要删除所有内容,那么我必须使用模拟行为来实现服务器,对于像这样的简单应用程序来说,这几乎是整个项目。我明白,当事情很大时,比编写几行 Perl 脚本来测试它确实有帮助。

现在我正在同时开发服务器和客户端,这样我至少可以手动测试,但这似乎不是一种干净的开发方式。唯一有帮助的是通过记录器建立连接隧道,这样我就可以看到经过的所有数据(使用IDEA的TunneliJ插件)。

使用自定义协议 TDD 网络应用程序的最佳方法是什么?我应该把所有东西都存起来然后就可以了吗?

I'm currently developing two Java networking applications for school projects. One over TCP and the other one over UDP. In both I have to implement simple custom protocol.

Even though I'm trying pretty hard, I can't find a way how to correctly test this kind of apps, or better develop with test first development.

If I have a client and I want real test without stubbing everything out, I have to implement server with simulated behaviour, which in case of simple apps like these is almost the whole project. I understand, that when something big, than writing few lines of Perl script to test it could really help.

Right now I'm developing server and client simultaneously, so that I can at least test by hand, but this doesn't seem like a clean way to develop. The only thing that is helping is tunneling the connection through logger, so that I can see all the data that goes through (using TunneliJ plugin for IDEA).

What is the best way to TDD a networking application with custom protocol? Should I just stub everything and be fine with it?

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

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

发布评论

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

评论(3

初懵 2024-08-17 23:56:51

将协议与网络层分离。一旦您可以向协议提供自己的数据,而无需通过网络堆栈,测试协议的逻辑将变得更加容易。即使您没有使用 Python,我还是建议您查看一下 Twisted 框架的结构。这是如何对网络应用程序进行单元测试的一个很好的示例。

Separate the protocol from the network layer. Testing the logic of the protocol will become easier once you can feed it your own data, without the need to go through the network stack. Even though you are not using Python, I'd suggest to look at the structure of the Twisted framework. It's a nice example of how to unit-test networking applications.

小…楫夜泊 2024-08-17 23:56:51

不久前我们也遇到了同样的问题。我们认为让两名开发人员来完成这项任务会更简单:一名开发服务器,另一名开发客户端。我们开始在同一个办公室工作,这样我们就可以更轻松地编码、测试、修改、重复。

总而言之,我认为这对我们来说是最好的解决方案。它使我们能够在不理想的条件下实际测试该程序。例如,我们的互联网出现了几次故障,我们的程序崩溃了,所以我们修复了它。它对我们来说效果很好,但如果您是独立开发人员,它可能不是适合您的解决方案。

无论您做什么,在编写自定义协议时,我都会查看 Wireshark 来监控您的网络流量,以确保所有数据包都是正确的。

We wound up with the same problem a while ago. We decided it was simpler to put two developers on the task: one to write the server and one to write the client. We started working in the same office so that we could code, test, modify, repeat a little bit more easily.

All in all, I think it was the best solution for us. It gave us the ability to actually test the program in conditions there were not ideal. For instance, our Internet went out a couple of times and our program crashed, so we fixed it. It worked rather well for us, but if you are a sole developer, it may not be the solution for you.

Whatever you do, when writing a custom protocol, I would check out Wireshark for monitoring your network traffic to make sure all of the packets are correct.

暮光沉寂 2024-08-17 23:56:51

在我的应用程序中,我有这样的代码,

    m_socket.receive(packet);

    doSomething(packet);

我模拟了接收,因此可以执行 doSomething() 需要执行的所有操作。

这对你来说在哪里会失败?在这里,您真正单元测试您的代码行为是否正确,您还可以模拟套接字发送,并设置您认为应该根据您的协议发送的内容的期望。

当然,我们实际上并没有测试协议的另一端是否满意。这就是集成测试。我总是渴望尽快接触 IT。当你与“另一端”互动时,你会发现有趣的东西。

你很幸运,可以控制两端,在这种情况下,我可能会花一些时间来创建合适的、可控的测试工具。

In my app I have code such as this

    m_socket.receive(packet);

    doSomething(packet);

I mock up the receive and hence can exercise everything that doSomething() needs to do.

Where does this break down for you? Here you are truly unit testing that your code behaves correctly, you can also mock the socket send, and se expectations for what you think should be sent according to your protocol.

We are of course not actually testing that the other end of the protocol is happy. That's integration testing. I always hanker after getting to IT as soon as possible. It's when you interact with the "other end" that you find the interesting stuff.

You are in the luck position of being in control of both ends, in that position I would probably spend some time instrument to create suitable, controllable test harnesses.

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