我正在测试一个类(除了与其他人交互之外)创建一个对象,该对象的字段由调用者传递的常量和值组成:
private String createService(Long organizationId, String prototypeId,
MedicalService medicalService)
{
ServiceType service = new ServiceType();
service.setClinic(organizationId.toString());
service.setType("0");
service.setPrototype(prototypeId);
service.setCode(medicalService.getCode());
service.setName(medicalService.getName());
service.setIndependent(true);
service.setRepeated(false);
return remoteWS.createService(service);
}
我应该测试每个字段是否设置正确?
我怀疑的原因是它会引入重复并降低可读性。我特别倾向于进行反射断言。
这只会检测到一些“愚蠢”的打字错误,例如如果两者都是 String
类型,则将 code
写入 name
字段。
这种重复合理吗?
最佳答案
解决这个问题的一种方法是:如果您有某种“共同”存在的“数据”,那么该数据就值得拥有其自己的类。
对于这种情况,你会使用 scala 所说的 value class对于 scala,或者 kotlin 提供的 data class 。换句话说:一个容器,其存在只是为了包装一组值。
其中的核心方面:例如,您为 equals()
方法提供合理的实现(当考虑 Java 术语时)。换句话说:您启用类似 dataObjectA.equals(dataObjectB)
的比较,它依次比较该类的所有字段。
然后您可以通过在单元测试中创建该数据类的实例来利用它,并携带所有预期值。
这是否值得付出努力的问题不是其他人可以告诉你的。您必须评估 A) 在该角落出现错误的可能性 B) 此类错误的成本。
从 TDD 的角度来看,您甚至会测试这些细节。
我个人的想法:有时候人必须要务实。在我看来,仅“记录”生产代码正在执行的操作的单元测试并没有太大帮助。尽管如此,有时除了这样写下来,别无他法。从这个意义上说:我建议测试这些细节,但是我会退一步设计一个解决方案,使编写相应的测试尽可能简单和直接。
换句话说:我会测试这些东西,但要确保我可以用最小的努力做到这一点。
关于unit-testing - 单元测试: allow for false-positive or bring duplication,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/45005279/