优秀实践之用单元测试测试下层依赖的默认值
【摘要】 这些天,在给项目servicecomb提交代码,升级其中的vertx和netty版本号,发现有单元测试用例跑不过https://github.com/apache/servicecomb-java-chassis/pull/2614 @Test public void testGetMaxFormAttributeSize() { Assert.assertEquals(8192,...
这些天,在给项目servicecomb提交代码,升级其中的vertx
和netty
版本号,发现有单元测试用例跑不过
https://github.com/apache/servicecomb-java-chassis/pull/2614
@Test
public void testGetMaxFormAttributeSize() {
Assert.assertEquals(8192, TransportConfig.getMaxFormAttributeSize());
ArchaiusUtils.setProperty("servicecomb.rest.server.maxFormAttributeSize", 3072);
Assert.assertEquals(3072, TransportConfig.getMaxFormAttributeSize());
}
通过这个用例可以拦截,如果新版本TransportConfig中依赖的底层默认值修改为非8192的问题。
对于底层依赖的其他项目,有些参数有统一的文件放置,甚至有些项目,参数分散在各个文件。相比升级后,逐个参数检查,通过单元测试能更有效的发现默认值的变化或移动再处理。我觉得这是一个很好的实践。推广到非library库中,我们维护的pulsar、mysql等组件,也可以通过ut测试来保证一些配置文件中的默认参数没有新增、删除或修改。
【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱:
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论(0)