未加星标

Moving 4-ward with Intern

字体大小 | |
[前端(javascript) 所属分类 前端(javascript) | 发布者 店小二04 | 时间 2017 | 作者 红领巾 ] 0人收藏点击收藏

Moving 4-ward with Intern

The motivation for Intern 4 is to make it easier to author tests with ES6+ features within tests, with or without transpilation.

Want to skim? Here’s the Intern Roadmap which lists our high level status for each Intern release going forward.

Or if you’re curious to know the details for our plans for Intern this year, read on:

Intern 4 Goals Loaderless Intern

When Intern began, AMD was the only practical way to effectively load modules both in a browser and within Node.js without a compile step. Since then, ES Modules (ESM) have become the preferred standard way of authoring modules, and various tools such as webpack have changed the way people think about module loading and bundling.

Given the diverse perspectives on how to load modules, we are removing module loading from Intern’s purview. While this may seem like we’re offloading work to the user, it will actually simplify test writing in most cases. Rather than requiring projects to adapt to Intern’s AMD environment, Intern 4 will adapt to the user’s environment.

The result is that Intern and its packages will be loaded like any other module, and Intern can be built/optimized for a target environment and/or loader. We believe this will make it simpler for users and developers to understand and use.

Leverage ES6+ and TypeScript as much as possible

Intern 4 has been completely refactored as a collection of packages that leverage modern ES6+ and TypeScript features. TypeScript gives us the benefits of types and interfaces, making our test interfaces predictable with an extra layer of accuracy and clarity.

For TypeScript users, it will be very difficult to accidentally mis-use Intern’s APIs. And for other users, you’ll simply use Intern as a normal package.

Beyond language syntax features, it will be possible to write async tests with features beyond Promises such as generators and async/await. We still have a fair amount of work to do to make instrumentation and functional testing more natural for ES6+ users that want to test non-transpiled code. We’ve also leveraged decorators to simplify writing reporter classes.

Simplify the architecture

Writing a testing stack that can work in any environment often leads to complexity. We’re working to simplify the architecture where possible as part of this refactoring effort. For example, we’re eliminating the ReporterManager class and simply having the Executor itself be the event hub. We’re also consolidating some of the runtime events, e.g. just testEnd , rather than testEnd , testSkip , testPass , and testFail .

Another area of complexity is browser vs. Node.js tests. Currently, the code has environment-specific branches throughout, whereas Intern 4 is separating code into environment-specific modules where necessary. Also with the emergence of more isomorphic javascript, the distinction between client and runner was becoming increasingly confusing, as well as the introduction of new features like performance benchmarking which might run in a browser or on the command-line. So we’re working to make it clearer how to use various test runners.

As part of the move away from assuming the presence of a module loader, Intern will no longer dynamically load modules. Instead, when the user loads a particular test executor (e.g. Node.js), all relevant code for that environment is loaded, e.g. all usable reporters, interfaces, and utility functions.

Intern will still have hook points to attach custom reporters or interfaces. And there will be convenience APIs for accessing built-in components.

Backwards compatibility

As with previous Intern major versions, we strive to maintain some reasonable level of backwards compatibility. At the very least, users shouldn’t have to completely rewrite all their existing tests, and we should provide an AMD wrapper to try to fully support existing test suites. However, the main goal is to end up with a better, cleaner architecture.


Moving 4-ward with Intern
Looking at the Architecture

Overall architectural changes for Intern 4 include:

Re-implement Intern in TypeScript with detailed typings Use environment-specific executors with static module loading The active Intern executor will exist as an intern global; test scripts will use this global to interact with Intern (e.g., to load interfaces or to examine the config) Reporters will be event listeners attached to the executor; any other interested code can also easily listen to intern events The browser version will be a single script that includes all Intern code and, when loaded, will implicitly instantiate a test executor Usage Model

Intern 4 will be used in the following way in different environments:

Node.js Load the Node.js test executor Parse command line arguments Create an executor instance using the initialize function, passing in configuration data The static Executor.create function became a standalone initialize function for improved flexibility This will instantiate a Node.js executor and assign it to the intern global Load test suites Suites, or at least the application code being tested (which will generally be loaded by suites) must be loaded after the test executor has been created for instrumentation (code coverage analysis, etc.) to work Run the executor Browser Load the browser script in a test page with a <script> tag This will instantiate a Browser test executor and assign it to a global intern variable Parse query arguments Configure the test executor ( intern.configure(...) ) Load suite scripts Run the test executor WebDriver

This will work much like the Node.js case, but the test executor can also be provided a list of paths to unit test suite modules and the path to a loader script. The unit tests will be loaded (using the provided loader script, if specified) and run in unit test mode in remote browsers.

Miscellaneous Musings

While we’re hopeful that the completion of our above-stated goals will address many of the open issues today, we also have our hearts set on improving Intern’s existing features includingintern-cli, SeleniumTunnel , performance benchmarking ,visual regression, and accessibility testing . And here we’ll also mention that we still have our sights set on:

Cucumber integration Improved testing sandbox Re-evaluating test authoring Simplifying the swap of core features such as assertion libraries and WebDriver implementations
Moving 4-ward with Intern
Help Us Grow the Intern Community

While it’s heartening to see growing community involvement, we have a lot of work to do! Here are a few ways you can contribute to this project:

Provide fixes, bugs, documentation, and examples Have your company sponsor the development of features ! Introduce your peers to Intern Discuss Intern’s benefits at Meetups, internal brownbags and on social media Join the SitePen team for guaranteed contributor time! Invite SitePen to present Intern at your next event Getting Help With Intern
Moving 4-ward with Intern

SitePen’s Intern workshop is a quick way to jumpstart your automated testing journey.Register today for an online workshop.


Moving 4-ward with Intern

Get help fromSitePen Support, our fast and efficient solutions to all things in application development.


Moving 4-ward with Intern

Let’s talk about how we can help your organization improve their approach to automated testing.


Moving 4-ward with Intern

Have a question? We’re here to help!Get in touch and let’s see how we can work together.

本文前端(javascript)相关术语:javascript是什么意思 javascript下载 javascript权威指南 javascript基础教程 javascript 正则表达式 javascript设计模式 javascript高级程序设计 精通javascript javascript教程

主题: Node.jsAMDJavaScriptJava
分页:12
转载请注明
本文标题:Moving 4-ward with Intern
本站链接:http://www.codesec.net/view/532357.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 前端(javascript) | 评论(0) | 阅读(38)