java - NatTable 的 JUnit 测试

Question

我想对 NatTable 内容进行普通 UI 测试(即，不使用 SWTBot 或其他 UI 测试框架)。

我的方法是创建一个 shell，添加我的自定义 NatTable，然后访问单元格并检查其内容(数据值、配置标签等):

// Note: this is Xtend code
@Before
def void setup()
{
    shell = new Shell(Display.getCurrent)
    shell.layout = new FillLayout
    parent = new Composite(shell, SWT.NONE)
    parent.layout = new GridLayout
    fixture = new MyNatTableViewer(parent) // this is my custom nattable impl under test
    shell.pack
    shell.visible = true
}

@Test
def void testLabel() 
{ 
    assertCellLabel(2, 2, "test-label");
}

def assertCellLabel(int row, int col, String expected)
{
    val labels = parameterTable.getCellByPosition(col, row)?.configLabels
    assertThat(labels).describedAs("Labels for row " + row + " col " + col).isNotNull
    assertThat(labels.labels).describedAs("Labels for row " + row + " col " + col).contains(expected)
}

为了测试我的其他组件，只需创建外壳和父复合体就足够了；我的测试工作不需要包装和设置可见。然而，对于 NatTable，如果单元格不可见，getCellByPosition() 将返回 null - 因此我添加了代码以打包并将 shell 设置为可见。这适用于小型表格(2 行和几列)。

遗憾的是，它不适用于大表。我怀疑这是因为视口(viewport)层不会创建不在可见区域中的单元格(据我所知，这是 NatTable 的优势 - 它只按需创建所需的结构)。这当然是正常运行时行为所需要的。

但是有没有一种(另一种)方法以有保证的方式获取单元格(换句话说，我可以让 NatTable/ViewportLayer 相信单元格是可见的，这样我就不会得到 null 只要单元格在内容方面存在？)

当然，我可以直接测试我的标签累加器、数据提供程序等，但我想在这里更多地从黑盒的角度来解决这个问题。

Answer 1

这个问题本身就是矛盾的。您要求使用黑盒方法来测试 NatTable，但您想更改 NatTable 在测试时的行为。这不是黑盒方法!

如果您真的想用黑盒方法进行测试，您需要确保单元格已被渲染。这可以通过触发滚动来完成，例如通过执行 ShowCellInViewportCommand。这是真正的黑盒方法，因为为不可见的单元格返回 null 是正确的结果。

如果您需要介于真正的黑匣子方法和利用内部知识(您要求的)的方法之间的东西，您必须找到实现目标的方法。

1. 在 ViewportLayer 下面的层上操作。通常可以使用 SelectionLayer。但是当然这不需要有任何意义，因为层堆栈可能因设置而异。 ViewportLayer 是将虚拟特性引入 NatTable 和滚动能力的层。它避免了对底层的访问。因此，询问其中一个将返回您期望的值。

2. 通过执行 TurnViewportOffCommand 禁用 ViewportLayer。这基本上是一种 hack，可能会在后面触发您可能不想要的其他内容。但我在其他情况下看到过该建议，因此想在这里命名。无论如何我不建议使用它!

请注意，当我们谈论黑盒测试时，这两种方法更像是 hack，因为您是在对组合进行假设。由于各种配置能力，它们不能普遍应用。

关于为什么需要设置 Shell 可见的隐藏问题。嗯，基本上是因为需要触发用于绘制和调整大小的 SWT 事件，以便根据 Shell 状态正确地开始 NatTable 的大小计算和打印。在我们的示例(也是纯 SWT)中，我们调用 Shell#open()。

作为对您的实现的最后评论，我不明白您为什么要对 NatTable 进行子类化。我们的 API 从未打算这样做。我想你这样做是为了做一些静态的预配置，例如层堆栈。但我个人不喜欢这种方法。每次有人扩展我们的类以覆盖某些内部方法时，它都会以问题或错误报告告终，因为行为会发生变化。但我认为这通常是开放 API 的问题，以便为开发人员提供最大可能的定制灵 active 。