在我们的项目中，它具有庞大的类和子关系，我们已经开发了几个月。另外，我们一直在开发junit测试用例。
自动单元测试通常很好，但是在现实生活中，这并不容易。管理单元测试体系结构比创建模拟对象和存根等更容易。此外，我们正在测试dao和service层。
问题是我们的类有这么多属性。（我知道这不是一个很好的面向对象的设计，而是传统的体系结构。）
例如; 客户类别具有58个属性，并且与地址，marsaccounts等相关。总的来说，如果要测试该类别，则必须创建输入，具有90个或更多属性的输入。
我们的体系结构对客户有很多业务规则，因此我们必须创建50多个客户输入来测试每个规则，方法或流程。
简而言之，您必须为所有属性创建4500个（90 x 50）属性，但为可靠的测试创建较少的属性（仅必要属性）。
准备测试输入既痛苦又烦人。想象一下，将2列添加到Customer对象，它们存储了关键值。看起来很容易，但是重构测试输入却是毁灭性的。
如何管理测试存根，如何克服庞大的输入集？
问候。
看来您只有两个选择：减少相关的属性或学习轻松设置具有大量属性的测试。
较少的属性：重构。由于我们不了解您的业务，因此没有人会为您提供更多详细的帮助。尝试找到控制某些逻辑的较小属性组，并仅使用那些属性来测试该逻辑。
简便的测试设置：您可以使用客户构建器。默认情况下，他们会使用一些标准/最常用的设置来创建客户，然后根据需要调整结果
customer = makeCustomer().withActiveStatus(false).withDebit(3000).build()
然后，当出现新属性时，您只需要makeCustomer()在一个地方更改即可。
您还可以使用参数化测试将一个测试用例定义为一个衬套，或从电子表格加载数据，这可能更易于维护。
通常，当出现新属性时，并不是说它会完全改变所有内容。通常，当该属性为非标准属性时，它只会在一处添加新的行为。因此通常只是将默认属性添加到构建器中，并进行一些覆盖该属性的测试
简化测试的另一种方法是进行属性测试（QuickCheck系列），尽管在业务逻辑中并不总是很容易使用它
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句