我们是两个正在写学士论文的学生,我们开发了一个 Windows 应用程序,它应该能够在各种沟通过程中帮助餐厅。从根本上说,它应该能够从客人发送给它的那一刻起就显示有关订单的信息。
我们在开发过程中省略了测试,但现在决定编写单元测试。尽管如此,我们发现我们现在可以写入系统的最合适的测试是集成测试,因为我们类中的所有方法都通过 LINQ to SQL 绑定(bind)到 SQL 存储过程。我们知道使用 stub 来伪造对数据库的依赖性,但是当我们的数据库已经与所有功能一起实现时,我们认为将几种方法作为集成测试一起测试会给我们带来更多值(value)。
如以下代码所示,我们已尝试遵循单元测试的指南,但这是编写集成测试的正确方法吗?
[Test]
public void SendTotalOrder_SendAllItemsToProducer_OneSentOrder()
{
//Arrange
Order order = new Order();
Guest guest = new Guest(1, order);
Producer producer = new Producer("Thomas", "Guldborg", "Beverage producer");
DataGridView dataGridView = new DataGridView { BindingContext = new BindingContext() };
order.MenuItemId = 1;
order.Quantity = 1;
//Act
guest.AddItem();
dataGridView.DataSource = guest.SendOrderOverview();
guest.SendOrder(dataGridView);
dataGridView.DataSource = producer.OrderOverview();
var guestTableOrder = producer.OrderOverview()
.Where(orders => orders.gtid == guest.GuestTableId)
.Select(producerOrder => producerOrder.gtid)
.Single();
//Assert
Assert.That(guestTableOrder, Is.EqualTo(guest.GuestTableId));
}
最佳答案
是的,一般来说,单元测试/集成测试就是这样写的。您遵守一些重要准则:
- 不同的 Act-Arrange-Assert 步骤
- 测试名称描述了这些步骤(也许它应该在末尾有类似“ShouldSendOneOrder”的东西,“Should”通常用于描述断言)。
- 每次测试一个断言。
我假设您还遵守其他准则:
- 测试是独立的:它们不会改变持久状态,因此不会影响其他测试。
- 测试实际用例:不要安排违反业务逻辑的星座,不要做不可能的事情。或者:模仿真实的应用程序。
但是,我也看到了令人侧目的事情。
不清楚您测试的哪个行为。我认为一些“行为”属于安排步骤。
producer.OrderOverview()
之类的方法让我怀疑域对象执行数据库交互。如果是这样,这将违反持久性无知。我认为应该有一种服务可以提供这种方法(但见下文)。不清楚为什么
dataGridView.DataSource = producer.OrderOverview();
是测试所必需的。如果是,这只会加剧最严重的一点:业务逻辑和 UI 纠缠在一起!!
- 像
guest.SendOrderOverview()
和producer.OrderOverview()
这样的方法很臭:为什么域对象应该知道如何展示它的内容?这是演示者 (MVP) 或 Controller (MVC) 或 View 模型 (MVVM) 应该负责的事情。 - 像
guest.SendOrder(dataGridView)
这样的方法是邪恶的。它将领域层与 UI 框架联系起来。这种固定的依赖关系已经够邪恶了,但是当然你还需要这个方法中 GridView 的值。因此,业务逻辑需要对某些 UI 组件有深入的了解。这违反了告诉 - 不要问原则。guest.SendOrder
应该有简单的参数来告诉它如何完成它的任务,域不应该有 any 对 any UI 框架的引用。
- 像
您真的应该解决后一点。将在不与 DGV 进行任何交互的情况下运行此测试作为您的目标。
关于c# - 如何在 NUnit 中编写集成测试?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/30232055/