Ver Fonte

Merge branch 'stable'

Piotrek Koszuliński há 6 anos atrás
pai
commit
e1656bb747

+ 0 - 22
docs/builds/guides/support/getting-support.md

@@ -19,28 +19,6 @@ Refer to {@link builds/guides/support/reporting-issues Reporting issues} guide f
 
 Make sure to tag your questions with ["ckeditor"](https://stackoverflow.com/questions/tagged/ckeditor) and ["ckeditor5"](https://stackoverflow.com/questions/tagged/ckeditor5) to reach the widest audience.
 
-## Gitter
-
-[CKEditor 5 Gitter channel](https://gitter.im/ckeditor/ckeditor5) is the place where you can discuss all matters that do not fit GitHub or Stack Overflow.
-
-Gitter is convenient for asking quick questions, however, it is not the best place for more complex topics which might interest other developers (Gitter logs are indexed via Google but rather poorly). Therefore, try to avoid lengthy discussions on topics which would make sense to be reported either on GitHub or Stack Overflow.
-
-DOs:
-
-* Is it a known bug that "..."?
-* Do you plan to tag the new release this week?
-* I can't find XYZ's documentation. Is it available somewhere?
-* I'm in Warsaw. Anyone for a coffee?
-
-DON'Ts:
-
-* How to extend the selection to the end of the block?
-* Could you implement support for XYZ?
-* I can't make X and Y work together in my app. I developed this plugin and...
-* The editor crashes if I press <kbd>Enter</kbd>. Please help.
-
-And most importantly, be kind to everyone.
-
 ## Commercial support
 
 CKEditor 5 also comes with commercial licensing benefits, such as direct support from the core CKEditor development team. Commercial licenses are designed with professionals and enterprises in mind.

+ 23 - 22
docs/framework/guides/contributing/testing-environment.md

@@ -11,50 +11,51 @@ Before reading this article we recommend getting familiar with the CKEditor 5 {@
 
 The CKEditor 5 testing environment uses a popular setup with [Karma](https://karma-runner.github.io), [webpack](https://webpack.github.io/), [babel-loader](https://github.com/babel/babel-loader) and [Istanbul](https://github.com/gotwarlost/istanbul). We created some [npm scripts](https://docs.npmjs.com/cli/run-script) which glue all these pieces and special requirements for CKEditor together.
 
-Each CKEditor package has its own tests suite (see for example the [engine's tests](https://github.com/ckeditor/ckeditor5-engine/tree/master/tests)), however, the test runner is available in the [`ckeditor5`](https://github.com/ckeditor/ckeditor5) package which is the central development environment. The actual code of the test runner is implemented in the [`@ckeditor/ckeditor5-dev-tests`](https://www.npmjs.com/package/@ckeditor/ckeditor5-dev-tests) package and can be easily reused outside of `ckeditor5`.
+Each CKEditor 5 package has its own tests suite (see for example the [engine's tests](https://github.com/ckeditor/ckeditor5-engine/tree/master/tests)), however, the test runner is available in the [`ckeditor5`](https://github.com/ckeditor/ckeditor5) package which is the central development environment. The actual code of the test runner is implemented in the [`@ckeditor/ckeditor5-dev-tests`](https://www.npmjs.com/package/@ckeditor/ckeditor5-dev-tests) package and can be easily reused outside of `ckeditor5`.
 
 ## Running automated tests
 
-In order to run the automated tests use the `yarn run test [<args>...]` command.
+In order to run the automated tests, use the `yarn run test [<args>...]` command.
 
-It accepts the following arguments (must be passed after the `--` option):
+It accepts the following arguments that must be passed after the `--` option:
 
 * `--watch` (alias `-w`) &ndash; Whether to watch the files and execute tests whenever any file changes.
-* `--source-map` (alias `-s`) &ndash; Whether to generate the source maps.
+* `--source-map` (alias `-s`) &ndash; Whether to generate useful source maps for the code.
 * `--coverage` (alias `-c`) &ndash; Whether to generate code coverage.
 * `--verbose` (alias `-v`) &ndash; Allows switching on webpack logs.
-* `--files` &ndash; Specifies tests files to run. Accepts a package name or a glob. Read more about the [rules for converting the `--files` option to a glob pattern](https://github.com/ckeditor/ckeditor5-dev/tree/master/packages/ckeditor5-dev-tests#rules-for-converting---files-option-to-glob-pattern).
-* `--browsers` &ndash; Browsers which will be used to run the tests. Defaults to `Chrome`.
-* `--debug` (alias `-d`) &ndash; Allows specifying custom debug flags. For example, the `--debug engine` option uncomments the `// @if CK_DEBUG_ENGINE //` lines in the code. The `--debug false` option turns the debugging mechanism off and leaves the lines starting with `// @if CK_DEBUG //` untouched.
+* `--files` &ndash; Specifies test files to run. Accepts a package name or a glob. Read more about the [rules for converting the `--files` option to a glob pattern](https://github.com/ckeditor/ckeditor5-dev/tree/master/packages/ckeditor5-dev-tests#rules-for-converting---files-option-to-glob-pattern).
+* `--browsers` &ndash; Browsers that will be used to run the tests. Defaults to `Chrome`.
+* `--debug` (alias `-d`) &ndash; Allows specifying custom debug flags. For example, the `--debug engine` option uncomments the `// @if CK_DEBUG_ENGINE //` lines in the code. Note that by default `--debug` is set to `true` even if you did not specify it. This enables the base set of debug logs (`// @if CK_DEBUG //`) which should always be enabled in the testing environment. You can completely turn off the debug mode by setting the `--debug false` option.
 
 ### Examples
 
 Run all tests with the code coverage check of the [`ckeditor5-core`](https://github.com/ckeditor/ckeditor5-core) package:
 
-```
+```bash
 yarn run test -c --files=core
 ```
 
 Run and watch the [engine's `view` namespace tests](https://github.com/ckeditor/ckeditor5-engine/tree/master/tests/view) and all the tests in [`ckeditor5-typing`](https://github.com/ckeditor/ckeditor5-typing):
 
-```
+```bash
 yarn run test -cw --files=engine/view,typing
 ```
 
 Run the `bold*.js` tests in the [`ckeditor5-basic-styles`](https://github.com/ckeditor/ckeditor5-basic-styles) package:
 
-```
+```bash
 yarn run test -cw --files=basic-styles/bold*.js
 ```
 
 ## Running manual tests
 
-In order to start the manual tests server use the `yarn run manual` task.
+In order to start the manual tests server, use the `yarn run manual` task.
 
 The task accepts the following options:
 
-* `--source-map` (alias `-s`) that generates useful source maps for the code.
-* `--additionalLanguages="ar,pl,..."` that passes extra languages to the [CKEditor 5 webpack plugin](https://www.npmjs.com/package/@ckeditor/ckeditor5-dev-webpack-plugin). Check out the {@link features/ui-language UI language guide} to learn more.
+* `--source-map` (alias `-s`) &ndash; Whether to generate useful source maps for the code.
+* `--additionalLanguages="ar,pl,..."` &ndash; Specifies extra languages to the [CKEditor 5 webpack plugin](https://www.npmjs.com/package/@ckeditor/ckeditor5-dev-webpack-plugin). Check out the {@link features/ui-language UI language guide} to learn more.
+* `--debug` (alias `-d`) &ndash; Allows specifying custom debug flags. For example, the `--debug engine` option uncomments the `// @if CK_DEBUG_ENGINE //` lines in the code. Note that by default `--debug` is set to `true` even if you did not specify it. This enables the base set of debug logs (`// @if CK_DEBUG //`) which should always be enabled in the testing environment. You can completely turn off the debug mode by setting the `--debug false` option.
 
 It starts the server available at http://localhost:8125.
 
@@ -64,16 +65,16 @@ A manual test consists of 3 files:
 
 * A `<name>.md` file with the test description.
 * A `<name>.js` file with the JavaScript part of the test (e.g. the code initializing an editor).
-* A `<name>.html` file with the HTML part of the test. It does not need to be an entire HTML page (with the doctype, etc.), it can be just these HTML elements that you want to define.
+* A `<name>.html` file with the HTML part of the test. It does not need to be an entire HTML page (with the doctype, etc.). It can include just the HTML elements that you want to define.
 
 All 3 files are combined together and create a single manual test.
 
-Example Markdown file:
+An example Markdown file:
 
 ```md
 ## Create a new link
 
-1. Select a fragment of regular text.
+1. Select a fragment of the regular text.
 2. Click the toolbar "Link" button.
 3. Check if the balloon panel attached to the selection appeared.
 4. Fill in the "Link URL" input in the panel.
@@ -81,14 +82,14 @@ Example Markdown file:
 6. Check if the selected text is converted into a link.
 ```
 
-Example HTML file:
+An example HTML file:
 
 ```html
 <head>
     <style>
         /*
           Some additional styles which this test needs.
-          And yes – the test builder will merge this tag with the head defined in a template.
+          And yes – the test builder will merge this tag with the head defined in the template.
         */
     </style>
 </head>
@@ -96,7 +97,7 @@ Example HTML file:
 <div id="editor">...</div>
 ```
 
-Example JavaScript file:
+An example JavaScript file:
 
 ```js
 /* globals console, window, document */
@@ -127,10 +128,10 @@ ClassicEditor
 
 ## Test suite and CI
 
-To ensure the highest quality, we maintain a complete test suite with a stable 100% of code coverage for each of the packages. As of May 2018, this means over 8000 tests and the number is growing. Since every package is tested separately, we implement lower-level tests for libraries and higher-level tests for end-user features.
+To ensure the highest quality, we maintain a complete test suite with a stable 100% of code coverage for each of the packages. As of September 2019, this means over 11000 tests and the number is growing. Since every package is tested separately, we implement lower-level tests for libraries and higher-level tests for end-user features.
 
-Such an extensive test suite requires a proper continuous integration service. We use [Travis CI](https://travis-ci.com/) as a build platform. This service ensures seamless and fast developer experience and allow us to focus on the job.
+Such an extensive test suite requires a proper continuous integration service. We use [Travis CI](https://travis-ci.com/) as a build platform. This service ensures seamless and fast developer experience and allows us to focus on the job.
 
 Besides automated tests, we also maintain a smaller set of manual tests. They help us verify whether something unexpected happens that might have been missed by the automated tests.
 
-When proposing a pull request make sure to add test(s) which verifies it. Every code change should be accompanied by a test which proves that it is needed. Such a strict approach to testing ensures that we have not only 100% of code coverage (which is quite easy to achieve and gives only illusory safety) but also a high level of coverage for cases which we failed to notice initially (and might do that again in the future).
+When proposing a pull request make sure to add test(s) that verifies it. Every code change should be accompanied by a test which proves that it is needed. Such a strict approach to testing ensures that we have not only 100% of code coverage (which is quite easy to achieve and gives only illusory safety) but also a high level of coverage for cases that we failed to notice initially (and might do that again in the future).