做网站产品资料表格,wordpress云端采集插件,建个普通网站,东莞外贸网站建设哪家好JUnit Rules的优势#xff0c;尤其是在进行集成测试时#xff0c;几乎不能被高估。 在本文中#xff0c;我们将阐明ExternalResource扩展的有用性。 在我们必须使用抽象外部资源的第三方库的情况下#xff0c;这些简化了灯具控制。 作为示例#xff0c;我们将看看如何基于… JUnit Rules的优势尤其是在进行集成测试时几乎不能被高估。 在本文中我们将阐明ExternalResource扩展的有用性。 在我们必须使用抽象外部资源的第三方库的情况下这些简化了灯具控制。 作为示例我们将看看如何基于Git提交日志消息来验证对条目列表的正确检索。 什么是集成测试 “关注点分离”可能是软件设计和实现中最重要的单个概念。 语用单元测试[HUTH03] 通常我们使用单元测试来检查一小段生产代码是否按预期工作。 但是重要的是要了解这类测试仅限于开发人员负责的代码。 为了澄清这一点请考虑合并第三方库来管理对文件数据库Web服务等的访问。 测试将隐式调用第三方组件的代码因为我们的被测系统 SUT依赖于这些组件DOC[MESZ07]。 如果外部资源之一不可用尽管开发人员的代码可能没有问题但它们将失败。 此外访问这些资源通常很慢并且设置测试装置通常很麻烦。 更不用说脆弱性了它是由不同库版本的潜在语义变化引起的。 所有这些缺点建议通过适配器抽象[FRPR10]将应用程序的代码与第三方代码分开。 不仅仅是抽象适配器组件可以在应用程序的问题域方面提供表达性的API它还允许使用轻量级的替代测试double 通常表示为嘲笑来替换基于第三方代码的实现。 使用JUnit进行测试 使用JUnit进行测试是Java开发人员可以学习的最有价值的技能之一。 无论您的背景是什么无论您是只是想建立一个安全网以减少桌面应用程序的性能下降还是要基于健壮且可重用的组件来提高服务器端的可靠性都需要进行单元测试。 弗兰克Frank写了一本书为使用JUnit进行测试的基本知识提供了深刻的切入点并为您准备了与测试有关的日常工作挑战做好了准备。 学到更多… 这消除了先前列出的有关单元测试的依赖性问题。 双重测试的设置费用低廉可以将测试中的系统与第三方代码隔离开并保持测试的快速和可靠[MESZ07]。 但是它剩下的工作是测试适配器组件的正确行为。 这是集成测试开始起作用的时候。 该术语指的是软件测试中的阶段在该阶段中将各个软件模块组合在一起并作为一个组进行测试[INTTES]。 公平地说我们使用适配器抽象将一个或多个第三方模块组合在一起以提供某种功能。 因为从应用程序的角度来看这样的适配器是低级组件所以这种策略隐式地导致了一种自下而上的方法即首先测试最低级别的组件然后再使用它来促进对更高级别的组件的测试。 您可能想知道为测试目的调整设计是否不是一件坏事。 但是通过使用适配器您可以确定应用程序和第三方代码之间的明确界限。 如果新的库版本引入的行为略有不同则只需调整适配器代码即可再次通过相应的集成测试。 您的实际应用程序代码包括单元测试将不受影响 此外您可以通过提供适当的适配器轻松切换到其他供应商。 因此遵循这种做法还可以带来更健康的应用程序设计。 [APPE15] 外部资源处理 不幸的是在编写集成测试时我们必须面对通过使用测试倍数来避免单元测试所遇到的问题。 特别是从编码角度来看安装测试夹具通常需要大量的精力。 最重要的是我们还必须妥善保管[MESZ07]。 例如这意味着我们可能需要在测试执行后重置外部资源的状态。 后者对于确保后续测试独立运行很重要。 这样一来测试所做的资源修改就不会伪造其后继者的验证结果。 为了减少设置和拆卸代码的重复开销将普通的段落交换到测试帮助程序类中似乎很自然。 考虑一下系统环境变量主数据记录等的创建删除或操作。 JUnit规则是特殊的测试助手它像AOP框架一样拦截测试方法调用。 与AspectJ中的环境建议相比它们可以在实际测试执行之前和/或之后做有用的事情。 例如可以在测试运行之前注册REST服务资源并在结束后自动将其删除。 JUnit为规则提供了方便的基类ExternalResource 这些规则用于在测试之前设置外部资源文件套接字服务器数据库连接等并保证随后将其拆除[EXRAPI]。 以下清单ServerRule显示了原理。 public class ServerRule extends ExternalResource {private final int port;public ServerRule( int port ) {this.port port;}Overrideprotected void before() throws Throwable {System.out.println( start server on port: port );}Overrideprotected void after() {System.out.println( stop server on port: port );}
} ServerRule的构造函数使用我们的虚拟服务器类型的端口号。 为了证明这个概念实际上我们不启动一个真实的但只打印出的调用含有消息这个号码before和after的回调挂钩。 下一个清单显示ServerRule的用法。 public class MyServerITest {Rulepublic final ServerRule serverRule new ServerRule( 5050 );Testpublic void foo() {System.out.println( code that fails without server access ); }
} 请注意该规则如何由带有Rule注释的公共非静态字段Rule 。 运行测试用例将导致以下输出。 start server on port: 5050
code that fails without server access
stop server on port: 5050 如您所见该规则确保测试代码在预期的环境先决条件内执行并自动进行内部管理。 为了加深这个主题让我们看一个更详细的示例该示例说明了规则管理的灯具与被测组件之间的相互作用。 设计用于Git集成测试的规则 标题图像显示了一个时间轴组件该组件通过可配置的ItemProvider适配器检索其Item列表。 捕获图片时使用的适配器类型从Git存储库读取条目。 每个项目代表当前存储库分支的提交。 该插图基于我为《 Testing with JUnit》一书开发的示例应用程序的屏幕截图。 因为它超出了本书的范围所以我借此机会对我申请编写JGit集成测试的GitRule助手进行了解释。 驱动程序是提供实用程序类其目的是简化建立包含任意提交分支等内容的git夹具存储库的任务。 为此我创建了一个GitRepository类型。 这通过JGit处理本地存储库上的存储库交互。 以下摘录应阐明概念。 public class GitRepository {private final File location;GitRepository( File location ) {this.location location;}public RevCommit commitFi1e( String fileName, String content, String message )throws IOException{createFi1e( fileName, content );addFi1es();return commit( message );}[...]
} 如您所见 GitRepository实例采用一个构造函数参数该参数引用本地Git仓库的工作目录。 但是请注意构造函数的可见性限制。 这是因为抽象不负责处理存储库资源的生命周期。 对于后者我们使用ExternalResource派生如下面的清单所示。 public class GitRule extends ExternalResource {private final SetFile repositories;public GitRule() {repositories new HashSet();}Overrideprotected void after() {repositories.forEach( repository - delete( repository ) );}public GitRepository create( File location ) {createRepositoryOnDisk( location );GitRepository result new GitRepository( location );repositories.add( location);return result;}private void createRepositoryOnDisk( File location ) {InitCommand init Git.init();init.setDirectory( location );init.setBare( false );callInit( init );}private static void callInit( InitCommand init ) {try {init.call().close();} catch( GitAPIException exception ) {throw new GitOperationException( exception );}}
} GitRule可以作为工厂存储特定测试所需的存储库资源。 此外一旦完成测试执行它就会跟踪正确处置所需的位置。 所示版本仅在磁盘上创建本地存储库但是当然可以对其进行增强以克隆远程存储库。 ItemProvider接口依赖于扩展类型Item的通用类型参数。 因此 GitItemProvider类型返回GitItem实例作为查找结果并且每个git项都是JGit RevCommit的封装。 这样说很明显第三方代码抽象可能会影响多个类。 以下代码段显示了一个简单的集成测试方案。 GitRule提供了适用于创建实际提交的存储库。 后者用于验证GitItem实例的正确实例化。 public class GitItemTest {Rule public final TemporaryFolder temporaryFolder new TemporaryFolder();Rule public final GitRule gitRule new GitRule();Testpublic void ofCommit() throws IOException {GitRepository repository gitRule.create( temporaryFolder.newFolder() );RevCommit commit repository.commitFi1e( file, content, message );GitItem actual GitItem.ofCommit( commit );assertThat( actual ).hasId( getId( commit ) ).hasTimeStamp( getTimeStamp( commit ) ).hasContent( getContent( commit ) ).hasAuthor( getAuthor( commit ) );}[...]
} 该测试使用TemporaryFolder规则来确保在可访问目录下创建存储库。 实际上使用临时文件夹规则应该使GitRule的资源删除GitRule多余。 但是由于它的默认清除机制不会检查资源删除是否成功无论如何硬检查仅适用于最新的JUnit版本所以我选择不依赖它。 这很重要因为使用JGit可以很容易地遇到打开文件句柄的问题。 此外测试的验证是通过定制的定制GitItemAssert断言类和一些实用程序方法静态导入完成的。 有了这个适当的位置之后我们准备看一下更复杂的场景。 public class GitItemProviderITest {private static final String CLONE_NAME test;private static final int INITIAL_COMMIT_COUNT 6;Rule public final TemporaryFolder temporaryFolder new TemporaryFolder();Rule public final GitRule gitRule new GitRule();private GitRepository repository;private GitItemProvider provider;private File remoteLocation;private File destination;Beforepublic void setUp() throws IOException {remoteLocation temporaryFolder.newFolder();repository createRepository( remoteLocation );destination temporaryFolder.newFolder();provider new GitItemProvider( remoteLocation.toURI().toString(),destination,CLONE_NAME );}Testpublic void fetchItems() throws IOException {int fetchCount INITIAL_COMMIT_COUNT / 3;ListGitItem actual provider.fetchItems( null, fetchCount );assertThat( actual ).isEqualTo( subList( 0, fetchCount ) ).hasSize( fetchCount );}private ListGitItem subList( int fromIndex, int toIndex ) {return repository.logAll().stream().map( commit - ofCommit( commit ) ).collect( toList() ).subList( fromIndex, toIndex );}[...]
} 设置与之前的测试相似。 但是我们的装置存储库是通过委派给createRepository方法来创建的。 为了简洁起见我在此省略了详细信息因为该方法仅创建具有INITIAL_COMMIT_COUNT提交的存储库。 被测试的GitItemProvider组件采用三个构造函数参数。 第一个是夹具库的位置它将由提供者克隆。 为此第二个参数定义一个目标目录而第三个参数将插入克隆存储库的文件夹名称。 在练习阶段组件从其克隆的存储库中获取可用提交的子集。 subList验证该列表该列表是由我们的灯具存储库中的方法subList计算得出的预期列表。 最后这些规则负责客房整理。 如果要查看完整的示例代码请参阅GitHub存储库https://github.com/fappel/Testing-with-JUnit上可用的示例应用程序源。 摘要 这篇文章介绍了如何在编写集成测试时将JUnit规则用于干净的资源管理。 我们已经对什么是集成测试有了基本的了解了解了ExternalResource测试实用程序扩展的工作原理并详细说明了使用示例。 当然它的意义不仅仅在于初见。 熟悉此处显示的原理后您可能会考虑研究其他主题例如使用ClassRule来处理持久性固定装置 规则链 环境变量等。 不能不告诉您我的书《 使用JUnit进行测试 》中的第6章“ 使用JUnit规则减少样板”可作为免费阅读样本 网址为https://www.packtpub.com/packtlib/book/Application%20Development/ 9781782166603/6 。 如果您还不厌倦我的麻烦请大胆前进并抓住机会深入研究JUnit规则的世界…… 因此请记住人们始终遵守规则–不要忘记分享知识55357;56841; 资源资源 [APPE15]Appel 使用JUnit测试 Packt Publishing2015年 [EXRAPI]ExternalResourceAPI DOC http //junit.org/apidocs/org/junit/rules/ExternalResource.html [FRPR10]FreemanPryce 不断发展的面向对象软件由Tests指导 Addison Wesley2010年 [HUTH03]HuntThomas 实用单元测试有限公司2003年2004年 [INTTES]WikipediaIntegrationTesting https //en.wikipedia.org/wiki/Integration_testing [MESZ07]Meszaros xUnit测试模式 Pearson EducationInc.2007年 翻译自: https://www.javacodegeeks.com/2015/09/clean-integration-testing-with-junit-rules-3.html
