我有一个@Parameterized.Parameters
public static Collection<Object[]> data() {
log.info("Starting test class for laan documents");
controller = new Controller();
List<Laan> calculations = controller
.getXMLValues(Controller.Type.LAAN)
.stream()
.map(object -> (Laan)object)
.collect(Collectors.toList());
ArrayList<Path> xmlFiles = new ArrayList<>();
calculations.forEach(s -> xmlFiles.add(s.getXmlPath()));
log.info("Getting log for " + xmlFiles.size() + " laan files");
logvalues = controller.getLogvalues(xmlFiles);
Collection<Object[]> params = new ArrayList<>();
for(Laan laan : calculations) {
if(laan.getDocumentType().equalsIgnoreCase("laan")) {
for(Logfile logfile : logvalues) {
if(logfile.getName().equalsIgnoreCase(laan.getName())) {
params.add(new Object[]{laan.getName(), laan, logfile});
}
}
}
}
log.info("");
return params;
}
的测试类，如下所示：
logfile大多数对象包含具有不同值的相同变量，但在某些情况下，assumeTrue(someCondition);中没有任何内容可以比较（这没有问题，在大多数情况下是正常的）。这些案例在测试方法{{1}}
现在测试类变得非常庞大且难以维护。目前，该课程中有大约30种测试方法，并且在接下来的日子里将增加约100种新的测试方法。我已经读过，创建一个新类并使用指向其他测试类的指针是不好的做法。那么我应该如何继续组织我的长测试类？
答案 0 :(得分：0)
您需要定义测试框架的体系结构。尝试通过其他目录和类分隔方法。例如： 如果您需要测试一些功能，如：LoginPage，Dashboard，Email - 它并不意味着您需要将所有方法保留在一个测试类中。创建基本的api： 的 com.myproject.steps
<强> com.myproject.suite
<强> com.myproject.scenarious
之后，如果您有只使用Dashboard的方法，请将它们移到DashBoardSteps中，将登录方法移到LoginPageSteps中。之后，从LoginPageScenario或DashboardScenario调用它们，这种方法将为您提供更舒适的条件，以便将来轻松支持。