1

我刚刚遇到了 Delegate-Model 设计（相对于 MVC）并想尝试一下，最近也一直在学习 GOOS 风格的 TDD 开发。所以我希望我的步行骨架测试看起来像这样：（我正在使用 JUnit）

@Test
public void userGeneratesEvent_DNotifiesM_MNotifiesDOfUpdatedData_DGetsNewDataFromM() {
    Model model = new Model();
    Delegate delegate = new Delegate(model);
    model.addListener(delegate);
    // Not sure how to "generate the user event" here
    assert( ... );
}

正如上面的评论，我的问题是我不确定如何从委托中正确生成用户事件。也许我对设计模式如何工作的理解不正确，但委托应该封装视图和控制器——我必须让视图从委托内部向控制器触发一个事件，但这种交互应该是“秘密的” “？

任何意见或建议表示赞赏。

4

1 回答 1

1

您的步行骨架测试应尽可能接近端到端。如果可以的话，您的测试应该从 GUI 一直到 Web 服务或数据库层。这验证了一切都可以正确连接，并且您可以自动部署并在生产中运行。

但是，使用实际 Web 服务和数据库进行的测试可能太慢或太脆弱而无法自动化。在这种情况下，您使用依赖注入在这些层之下进行测试。

对于测试 GUI，您可以使用 GUI 测试框架通过 GUI 本身进行测试（这是他们在 GOOS 中所做的）。如果您使用 Swing，我推荐FEST。另一种更可靠且允许快速验收测试的方法是在 GUI 层下方进行测试。但为此，您应该使用 MVP 或 MVVM 而不是 Delegate-Model

我仍然坚持如何正确地以编程方式引发用户事件。例如，用户通过 UI 在表中添加一行，我在最后断言模型中的行数等于 1。我是否必须打破 Delegate 的封装才能做到这一点？

您要么必须：打破封装，使用诸如 MVP/MVVM 之类的模式，让您可以在视图下进行测试，或者使用 FEST 通过 GUI 进行测试。我建议使用 FEST 通过自动单击组件来引发事件并验证 JTable 是否具有给定的行数。FEST 测试相当可靠，尽管速度很慢，所以你不应该用它来编写单元测试。

如果您的应用程序增长到合适的大小（> 3000 LOC），您可以考虑重构为 MVP/MVVM，因为您将从代码重用和更快/可靠的端到端测试中获得足够的好处，以证明复杂性是合理的。您的 FEST 测试和单元测试（在模型上）不应在此重构期间中断，并将帮助您安全地重构。当您的演示者/视图模型是一个单独的类时，您可以直接在它们上调用用户事件并验证（使用模拟）/断言添加了额外的表行。

于 2012-06-05T19:51:59.497 回答