Question

我们是两名学生撰写我们的学士论文，我们开发了一个Windows应用程序，它应该能够帮助餐厅进行各种沟通。从根本上说，它应该能够在客人发送订单的那一刻起提供有关订单的信息。

我们在开发过程中省略了测试，但现在决定编写单元测试。然而，我们发现我们现在可以写入系统的最合适的测试是集成测试，因为我们类中的所有方法都通过LINQ to SQL绑定到SQL存储过程。我们知道使用存根来伪造数据库的依赖关系，但是当我们的数据库已经与所有函数一起实现时，我们认为它将为我们提供更多的价值来测试几个方法作为集成测试。

如下面的代码所示，我们尝试按照指南行进行单元测试，但这是编写集成测试的正确方法吗？

import javax.swing.*;
import java.awt.*;
public class MyPanel extends JPanel{
    public void paintComponent(Graphics g){  
        super.paintComponent(g);
        Graphics2D g2 = (Graphics2D)g;
        g2.drawRect(20,20,20,20);
        g2.setColor(Color.blue);
        g2.fillOval(50,20,20,20);
        g2.drawString("Hello World", 120, 50);
    }//end painComponent 
}//end test class

Answer 1

是的，一般来说，这就是如何编写单元测试/集成测试。您遵守一些重要的指导原则：

独特的行动 - 安排 - 断言步骤
测试名称描述了这些步骤（可能最后应该有类似“ShouldSendOneOrder”的东西，“应该”通常用于描述断言）。
每次测试一次断言。

我认为你也遵守其他准则：

测试是独立的：它们不会改变持久状态，因此它们不会影响其他测试。
测试现实用例：不要安排违反业务逻辑的星座，不要做不可能的行为。或者：模仿真实的应用程序。

然而，我也看到引起人们注意的事情。

您测试哪种行为并不明确。我认为一些“行为”属于安排步骤。
像producer.OrderOverview()这样的方法让我怀疑域对象执行数据库交互。如果是这样，这将违反持久性无知。我认为应该有一种提供这种方法的服务（但见下文）。
目前尚不清楚为什么dataGridView.DataSource = producer.OrderOverview();是测试所必需的。如果是这样，这只会加剧最严重的一点：
业务逻辑和用户界面纠缠在一起！
- guest.SendOrderOverview()和producer.OrderOverview()等方法臭：为什么域对象应该知道如何呈现其内容？这是演示者（MVP）或控制器（MVC）或视图模型（MVVM）应该负责的事情。
- 像guest.SendOrder(dataGridView)这样的方法是邪恶。它将域层与UI框架联系起来。这个固定的依赖是很邪恶的，当然你也需要这个方法里面的网格视图中的值。因此，业务逻辑需要对某些UI组件有深入了解。这违反了告诉 - 不要问原则。 guest.SendOrder应该有简单的参数来告诉它如何执行其任务，并且域不应该任何引用任何 UI框架。

你真的应该解决后一点。让您的目标是在没有与DGV进行任何交互的情况下运行此测试。

Answer 2

如果继续在课堂上绑定sql，那么测试不是一个大问题。

当程序逻辑非常简单时，您可以使用此方法，但我建议您研究The Repository Pattern，因为逻辑变得更加复杂。

如何在NUnit中编写集成测试？

2 个答案: