Java 给定场景的设计和测试方法

这不是家庭作业。而是一种了解

设计最佳实践的实践，实施和单元测试

一个特定的场景，因此，从理解的角度来看，解释为什么采用了一种特定的方法与其他方法相比较的讨论将非常有助于更好地理解如何处理类似的情况

如何从设计、实现和单元测试的角度处理以下场景

场景

说话者和听者互相交流。演讲者可以向听众表达情感：

微笑、愤怒、礼貌、笑话、愤怒等。

听者对每次交流（说点什么、攻击、防御、忽略等）都给出适当的回应

问题

• 侦听器对象的反应规则是什么
• 如何使用UML进行设计，并通过使用文本输出进行模拟来实现
• 检查此场景的正确实现的JUnit测试用例是什么

---

为了回答您的最后一个问题（关于JUnit），我将实现以下内容：

对每个有效输入进行测试，确认相应的输出

给出无效输入并确认此场景得到适当处理的测试（如果设计良好，您的接口可能不允许无效输入）

我不会写一个单元测试来检查每个情绪/反应。为什么不呢？如果一个测试失败了，那么整个单元测试都失败了，您将不知道接下来的哪些测试可能会失败。调试时，确定完整的响应集可能很重要，过早退出的测试会删除此功能

---

这里有一个（可能有点旧，但仍然相关）

以下步骤对于任何开发都非常重要

需求收集 冻结和记录准确的要求。起草准确的用例非常有帮助

设计 设计解决方案。根据项目的性质，可以选择不同的方法

• 增量模式： 对于一个具有短期可交付成果和评审的长期项目，增量模式非常有用
• 具体模式： 在这里，您可以彻底地设计应用程序。释放周期更长。每个功能都是先完成然后交付的

使用UML下面的图表很重要

• 类图： 应该详细列出所有类。这里可以详细介绍接口、抽象类、助手类和第三方API的使用
• 序列图： 应该列出项目中所有列出的用例的操作流程

这里应该包括使用适当的设计模式。测试用例应该与用例相匹配，通常与每个用例一个或多个测试用例相关

实际上这里有很多东西要描述。我提供的是在实施项目时应该采取的方法

考虑到您的应用程序，将其分解为不同的部分有助于简化设计。大体上，我可以想到以下几件作品

实体-说话者、听者

表达式-表达式列表

规则-说话人表达的反应表达形式的规则

通信-通信层，用于说话人对听话人（类似于广播）和听话人对说话人（类似于点对点队列）

---

你能展示一下这两个测试用例以及一个关于检查情绪/反应的测试用例的实现情况吗？我不能轻易做到这一点，因为它与你的实现密切相关。但您只需对从测试代码收到的响应执行assertEquals（预期、实际）。请参见上面链接的教程。