在我的Vaadin GUI应用程序中,有很多方法如下所示。
@Override
protected void loadLayout() {
CssLayout statusLayout = new CssLayout();
statusLayout.addComponent(connectedTextLabel);
statusLayout.addComponent(connectedCountLabel);
statusLayout.addComponent(notConnectedTextLabel);
statusLayout.addComponent(notConnectedCountLabel);
connectionsTable.getCustomHeaderLayout().addComponent(statusLayout);
connectionsTable.getCustomHeaderLayout().addComponent(commandLayout);
connectionsTable.getCustomHeaderLayout().addComponent(historyViewCheckbox);
bodySplitter.addComponent(connectionsTable);
bodySplitter.addComponent(connectionHistoryTable);
bodySplitter.setSplitPosition(75, Sizeable.Unit.PERCENTAGE);
bodySplitter.setSizeFull();
bodyLayout.addComponent(bodySplitter);
if (connectionDef.getConnectionHistoryDef() == null) {
historyViewCheckbox.setVisible(false);
}
if (connectionDef.getConnectionStatusField() == null || connectionDef.getConnectedStatusValue() == null || connectionDef.getConnectedStatusValue().isEmpty()) {
connectedTextLabel.setVisible(false);
connectedCountLabel.setVisible(false);
notConnectedTextLabel.setVisible(false);
notConnectedCountLabel.setVisible(false);
}
}
protected void setStyleNamesAndControlIds() {
mainLayout.setId("mainLayout");
header.setId("header");
footer.setId("footer");
propertyEditorLayout.setId("propertyEditorLayout");
propertyEditor.setId("propertyEditor");
mainLayout.setStyleName("mainLayout");
propertyEditorLayout.setStyleName("ui_action_edit");
header.setStyleName("TopPane");
footer.setStyleName("footer");
}
这些方法用于设置GUI的布局。它们不会产生单一的不同输出。这些方法中几乎每一行都在做一个单独的工作,这与其他几乎没有关系。
通常,在对方法进行单元测试时,我会检查方法的返回值,或者验证对有限数量的外部对象(如数据库连接)的调用。
但是,对于上述方法,没有这样的单一输出。如果我为这些方法编写单元测试,我的测试代码检查每个方法调用都发生在方法的每一行中,最后,它看起来几乎就像方法本身。
如果有人以任何方式更改了代码,测试将会中断,他们必须更新测试以匹配更改。但是,由于测试没有检查浏览器中绘制的实际用户界面,因此无法保证更改实际上没有破坏任何内容。
例如,如果有人更改了控件的样式名称,则必须使用新样式名称更新测试代码,测试将通过。但是,对于实际工作没有任何问题的东西,他也必须改变相关的scss样式文件。但是测试没有为检测这个问题做出任何贡献。同样适用于布局设置代码。
除了将代码覆盖率等级保持在更高水平之外,是否有编写上述单元测试的优势?对我来说,它感觉无用,并且编写测试来比较方法的反编译字节码和在测试中保持为字符串的原始反编译字节码看起来比这些类型的测试好得多。
答案 0 :(得分:2)
除了以外,编写上述单元测试是否有任何优势 将代码覆盖率保持在更高水平?
是的,如果你采取明智的做法。正如您所说,测试控件具有特定样式可能没有意义。因此,请将测试重点放在可能会破坏的代码部分。如果有任何条件逻辑用于生成UI,请测试该逻辑。然后,测试将保护您的代码免受可能破坏您逻辑的未来更改。
至于您对不会返回值的测试方法的评论,您可以通过多种方式解决这个问题。
最后考虑UI的单元测试是否适合您和您的组织。用户界面通常难以进行单元测试(正如您所指出的那样)。许多公司为其UI编写功能测试。这些是驱动实际产品UI的测试。这与不需要完整产品且针对非常小的功能单元的单元测试非常不同。
答案 1 :(得分:0)
这是一个简单的示例,您可以查看如何飞越您的应用程序并尝试所需的内容。这是vaadin 8,CDI& Wildfly Swarm示例,绝不是测试Vaadin应用程序UI的唯一方法。