diff --git a/.travis.yml b/.travis.yml new file mode 100644 index 0000000000..68fbf6d87c --- /dev/null +++ b/.travis.yml @@ -0,0 +1,11 @@ +language: node_js + +node_js: + - "0.10" + - "0.12" + +before_script: + - npm install -g gulp + - gulp + +script: npm test diff --git a/package.json b/package.json index 06152b4fa8..2f8af95a5f 100644 --- a/package.json +++ b/package.json @@ -4,7 +4,7 @@ "description": "Lightweight, robust, elegant syntax highlighting. A spin-off project from Dabblet.", "main": "prism.js", "scripts": { - "test": "echo \"Error: no test specified\" && exit 1" + "test": "mocha tests/testrunner-tests.js && mocha tests/run.js" }, "repository": { "type": "git", @@ -18,10 +18,12 @@ "license": "MIT", "readmeFilename": "README.md", "devDependencies": { + "chai": "^2.3.0", "gulp": "^3.8.6", "gulp-concat": "^2.3.4", "gulp-header": "^1.0.5", "gulp-rename": "^1.2.0", - "gulp-uglify": "^0.3.1" + "gulp-uglify": "^0.3.1", + "mocha": "^2.2.5" } } diff --git a/test-suite.html b/test-suite.html new file mode 100644 index 0000000000..accd149d92 --- /dev/null +++ b/test-suite.html @@ -0,0 +1,147 @@ + + +
+ + + +Prism has a test suite, that ensures that the correct tokens are matched.
+Running the test suite is simple: just call npm test
.
All test files are run in isolation. A new prism instance is created for each test case. This will slow the test runner a bit down, but we can be sure that nothing leaks into the next test case.
+Thank you for writing tests! Tests are awesome! They ensure, that we can improve the codebase without breaking anything. Also, this way, we can ensure that upgrading Prism is as painless as possible for you.
+You can add new tests by creating a new test case file (with the .test
file extension) in the tests directory which is located at /tests/languages/${language}
.
All tests are sorted into directories in the tests/languages
directory. Each directory name encodes, which language you are currently testing.
All language names must match the names from the definition in components.js
.
Just put your test file into the directory of the language you want to test.
+So, if you want to test CSS, put your test file in /tests/languages/css
to test CSS only. If you create a test case in this directory, the test runner will ensure that the css
language definition including all required language definitions are correctly loaded.
If you want to test language injection, you typically need to load two or more languages where one language is the “main” language that is being tested, with all other languages being injected into it.
+You need to define multiple languages by separating them using a +
sign: markup+php
.
The languages are loaded in order, so first markup (+ dependencies) is loaded, then php (+ dependencies). The test loader ensures that no language is loaded more than once (for example if two languages have the same dependencies).
+By default the first language is the main language: markup+php
will have markup
as main language. This is equal to putting your code in the following code block:
...
+<pre><code class="language-markup">
+ <!-- your code here -->
+</code><pre>
+...
+
+ If you need to load the languages in a given order, but you don't want to use the first language as main language, you can mark the main language with an exclamation mark: markup+php!
. This will use php
as main language. (You can only define one main language. The test runner will fail all tests in directories with more than one main language.)
Note: by loading multiple languages you can do integration tests (ensure that loading two or more languages together won't break anything).
+At first you need to create a new file in the language directory, you want to test.
+Use a proper name for your test case. Please use one case of the following conventions:
+issue{issueid}
: reference a github issue id (example: issue588.test
).{featurename}_feature
: group all tests to one feature in one file (example: string_interpolation_feature.test
).{language}_inclusion
: test inclusion of one language into the other (example: markup/php_inclusion.test
will test php inclusion into markup).You can use all conventions as a prefix, so string_interpolation_feature_inline.test
is possible. But please take a minute or two to think of a proper name of your test case file. You are writing code not only for the computers, but also for your fellow developers.
The structure of a test case file is as follows:
+
+... language snippet...
+----
+... the simplified token stream you expect ...
+
+ Your file is built up of two or three sections, separated by three or more dashes -
, starting at the begin of the line:
The easiest way would be to look at an existing test file:
+var a = 5;
+
+----------------------------------------------------
+
+[
+ ["keyword", "var"],
+ " a ",
+ ["operator", "="],
+ ["number", "5"],
+ ["punctuation", ";"]
+]
+
+----------------------------------------------------
+
+This is a comment explaining this test case.
+ While compiling, Prism transforms your source code into a token stream. This is basically a tree of nested tokens (or arrays, or strings).
+As these trees are hard to write by hand, the test runner uses a simplified version of it.
+It uses the following rules:
+Token
objects are transformed into an array: [token.type, token.content]
(whereas token.content
can be a nested structure).For further information: reading the tests of the test runner (tests/testrunner-tests.js
) will help you understand the transformation.
The test runner itself is tested in a separate test case. You can find all “test core” related tests in tests/testrunner-tests.js
.
You shouldn't need to touch this file ever, except you modify the test runner code.
+The global test flow is at follows:
+