https://docs-old.ckeditor.com/api.php?action=feedcontributions&feedformat=atom&user=GarryyaoCKSource Docs - User contributions [en]2026-05-21T12:03:09ZUser contributionsMediaWiki 1.29.1https://docs-old.ckeditor.com/index.php?title=CKEditor_3.x/Developers_Guide/Installation&diff=5310CKEditor 3.x/Developers Guide/Installation2010-12-01T05:36:56Z<p>Garryyao: Add upgrade installation instructions.</p>
<hr />
<div>Installing CKEditor is a easy task. Just follow these simple steps: <br />
<br />
== Installation procedures ==<br />
<br />
=== Fresh installation ===<br />
#'''Download''' the latest version of the editor from our web site: http://ckeditor.com/ <br />
#'''Extract''' (decompress) the downloaded file to a directory called "ckeditor" in the root of your web site<br />
'''Note:''' You can place the files in whichever path at your web site. "ckeditor" is the default one. <br />
<br />
=== Upgrade installation ===<br />
# Rename your old editor folder to a backup, as e.g. "ckeditor_old"<br />
# '''Extract''' (decompress) the downloaded file to the original editor directory, e.g. "ckeditor"<br />
# Copy all configuration files that '''you have changed''' to their corresponding position in the new directory, these could includes but not limit to the following files:<br />
* config.js<br />
* content.css<br />
* plugins/templates/templates/default.js<br />
* plugins/styles/styles/default.js<br />
* plugins/styles/styles/default.js<br />
* plugins/pastefromword/filter/default.js<br />
<br />
== Verify the installation ==<br />
<br />
The editor comes with a few sample pages that can be used to verify that installation proceeded properly. Take a look at the _samples directory. <br />
<br />
To test your installation just call the following page at your web site: <br />
<pre>http://&lt;your site&gt;/&lt;CKEditor installation path&gt;/_samples/index.html<br />
<br />
For example:<br />
http://www.example.com/ckeditor/_samples/index.html<br />
</pre></div>Garryyaohttps://docs-old.ckeditor.com/index.php?title=CKeditor_3.x/Users_Guide/NonEditable_Contents&diff=3727CKeditor 3.x/Users Guide/NonEditable Contents2010-06-21T07:30:31Z<p>Garryyao: </p>
<hr />
<div>== Overview ==<br />
<br />
Non-editable, read-only contents in WYSIWYG mode document could be achieved by specifying the standard-compliant [http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#contenteditable contenteditable] attribute on the element, this will result in such element as well as it's content being '''unable to modify by editor keystrokes, commands and also dialogs''', while remains displaying in the same way as ordinary elements (except for some special cases, e.g. in IE, non-editable inline elements are displayed as 'inline-block') in editor, which makes it possible to present '''"placeholder"''' region that are not intended to be modified by the end user while keeps informatively rich (comparing to an image place holder).<br />
<br />
== Example ==<br />
The following HTML content defines one read-only paragraph and one other contains a non-editable span.<br />
<pre><br />
<p>First paragraph <b>editable</b>.</p><br />
<p contenteditable="false">Second paragraph is read-only.</p><br />
<p>Third paragraph with <span contenteditable="false"> non-editable content</a>.</p><br />
</pre><br />
== Editor behavior ==<br />
# When executing an editor command, e.g. applying one style on a selection that contains such element, editor behaves as if the selection range is split up by this element into multiple slices of ranges thus the style are applied onto each range except for the element.<br />
# When navigating inside the document with keytrokes, e.g. Left/Right Arrow, to move cross such element, cursor will avoid from entering the element but jump over to the other side of it.<br />
# The result of deletion requests, e.g. press Del/Backspace keys, beside such element is browser dependent, it will either delete the entire element (IE,Safari,Chrome) or preventing the element from removed (Firefox).<br />
# Left single click on the non-editable element will select the entire element.<br />
# Right single click to open context menu on non-editable element will not display menu items that could modify the element.<br />
# Open dialogs on non-editable element will not load the element into dialog fields for modification.<br />
<br />
== Known limitations ==<br />
* Nested editable element inside non-editable is not supported yet.<br />
* Table element in IE can't be made as non-editable, see this [http://dev.fckeditor.net/ticket/5655 ticket].<br />
<br />
== Availability ==<br />
Since CKEditor '''3.4'''</div>Garryyaohttps://docs-old.ckeditor.com/index.php?title=CKeditor_3.x/Users_Guide/NonEditable_Contents&diff=3726CKeditor 3.x/Users Guide/NonEditable Contents2010-06-17T16:11:05Z<p>Garryyao: Init page</p>
<hr />
<div>== Overview ==<br />
<br />
Non-editable, read-only contents in WYSIWYG mode document could be achieved by specifying the standard-compliant [http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#contenteditable contenteditable] attribute on the element, this will result in such element as well as it's content being '''unable to modify by editor keystrokes, commands and also dialogs''', while remains displaying in the same way as ordinary elements (except for some special cases, e.g. in IE, non-editable inline elements are displayed as 'inline-block') in editor, which makes it possible to present '''"placeholder"''' region that are not intended to be modified by the end user while keeps informatively rich (comparing to an image place holder).<br />
<br />
== Example ==<br />
The following HTML content defines one read-only paragraph and one other contains a non-editable span.<br />
<pre><br />
<p>First paragraph <b>editable</b>.</p><br />
<p contenteditable="false">Second paragraph is read-only.</p><br />
<p>Third paragraph with <span contenteditable="false"> non-editable content</a>.</p><br />
</pre><br />
== Editor behavior ==<br />
# When executing an editor command, e.g. applying one style on a selection that contains such element, editor behaves as if the selection range is split up by this element into multiple slices of ranges thus the style are applied onto each range except for the element.<br />
# When navigating inside the document with keytrokes, e.g. Left/Right Arrow, to move cross such element, cursor will avoid from entering the element but jump over to the other side of it.<br />
# The result of deletion requests, e.g. press Del/Backspace keys, beside such element is browser dependent, it will either delete the entire element (IE,Safari,Chrome) or preventing the element from removed (Firefox).<br />
# Left single click on the non-editable element will select the entire element.<br />
# Right single click to open context menu on non-editable element will not display menu items that could modify the element.<br />
# Open dialogs on non-editable element will not load the element into dialog fields for modification.<br />
<br />
== Known limitations ==<br />
* Nested editable element inside non-editable is not supported yet.<br />
* Table element in IE can't be made as non-editable, see this [http://dev.fckeditor.net/ticket/5655 ticket].</div>Garryyaohttps://docs-old.ckeditor.com/index.php?title=FCKeditor_3.x/Design_and_Architecture/Coding_Style&diff=2841FCKeditor 3.x/Design and Architecture/Coding Style2010-01-31T11:37:20Z<p>Garryyao: Adding two whitespaces rules.</p>
<hr />
<div>= Coding Style Guidelines =<br />
<br />
These guidelines where defined based on mixed common standards mainly related to Java programming. It aims to reflect the generally accepted standards for JavaScript coding with some minor adjustments.<br />
<br />
It is quite common to take the Java style to write JavaScript code, assuming it is a "cut-down" version of Java. Although JavaScript has an indirect relation with Java, apart from the similar "C <br />
== General Recommendations ==<br />
<br />
Any violation to the guide is allowed if it enhances readability. <br />
<br />
If the name "CKEditor" is used, if must always be written with "CKE" uppercased concatenated with "ditor" in lowercase. The following usages are wrong: "CKeditor", "ckEditor", "CK Editor", etc. Exceptions are made for directories and file names, which must always be lowercased, and the CKEDITOR namespace name. <br />
<br />
If the name "FCKeditor" is used, it must always be written with "FCK" uppercased concatenated with "editor" in lowercase. The following are wrong: "FckEditor", "FCKEditor", "fckEditor", "FCK Editor", and so on. Exception is made for directory names, where all chars "should" be in lowercase. <br />
<br />
The name "JavaScript" should be written with both the "J" and "S" in uppercase. The following are wrong: "Javascript", "javascript", etc.<br />
<br />
== Naming Conventions ==<br />
<br />
=== Generic Name Conventions ===<br />
<br />
The ROOT namespace has a fixed name: CKEDITOR. <br />
<pre>CKEDITOR<br />
</pre> <br />
Names representing namespaces must be all lowercase. <br />
<pre>CKEDITOR.dom, CKEDITOR.env, CKEDITOR.ui<br />
</pre> <br />
Names representing public classes and public global objects must be in PascalCase. <br />
<pre>CKEDITOR.dom.Document, CKEDITOR.Util<br />
</pre> <br />
Names representing constants must be all UPPERCASE. <br />
<pre>CKEDITOR.STATUS_COMPLETE, CKEDITOR.EDITMODE_WYSIWYG, CKEDITOR.CTRL<br />
</pre> <br />
Names representing public methods must be verbs and written in camelCase. <br />
<pre>appendStyleSheet(), getElement (), setTimeout()<br />
</pre> <br />
Names representing public properties must be nouns and written in camelCase. <br />
<pre>name, document, targetWindow<br />
</pre> <br />
Names representing private methods must be verbs and written in camelCase prefixed with an underscore. <br />
<pre>_doInternalStuff()<br />
</pre> <br />
Names representing private properties must be nouns and written in camelCase prefixed with an underscore. <br />
<pre>_internalCounter, _prefix<br />
</pre> <br />
Abbreviations and acronyms should not be uppercase when used as name. <br />
<pre>setHtml(), XmlDocument<br />
NOT<br />
setHTML(), XMLDocument<br />
</pre> <br />
All names should be written in English.<br />
<br />
=== Specific Name Conventions ===<br />
<br />
The prefixes "get" and "set" may be used on methods that get or set properties which require computation.<br />
<pre>setArrayCount(), getFormattedValue()<br />
</pre> <br />
The prefix "checkIs" may be used on methods which return boolean states which require computation.<br />
<pre>checkIsValid(), checkIsEmpty()<br />
</pre> <br />
Abbreviations in names should be avoided.<br />
<pre>getDirectoryName(), applicationCommand<br />
NOT<br />
getDirName(), appCmd<br />
</pre> <br />
== Files ==<br />
<br />
All files must be named in all lower case.<br />
<br />
Classes and global objects should be declared in individual files with the file name matching the class/object name.<br />
<pre>fckbrowserinfo.js, fcktoolbarbutton.js<br />
</pre> <br />
== Layout ==<br />
<br />
For indentation, the TAB should be used. Development IDEs should be configured to represent TABs as 4 spaces. <br />
<pre>if ( test )<br />
{<br />
if ( otherTest )<br />
doSomething();<br />
doMore();<br />
}<br />
</pre> <br />
Block layout should be as illustrated. <br />
<pre>while (&nbsp;!done )<br />
{<br />
doSomething();<br />
done = moreToDo();<br />
}<br />
</pre> <br />
Single statement (single line only) if/else/while/for could (preferably) be written without brackets, but never in the same line. <br />
<pre>if ( condition )<br />
statement;<br />
<br />
while ( condition )<br />
statement;<br />
<br />
for ( initialization&nbsp;; condition&nbsp;; update )<br />
statement;<br />
</pre><br />
The above rule is not valid for nested blocks, like the following:<br />
<pre>if ( condition )<br />
{<br />
if ( anotherCondition )<br />
statement;<br />
}<br />
<br />
// WRONG:<br />
if ( condition )<br />
if ( anotherCondition )<br />
statement;<br />
</pre> <br />
The incompleteness of split lines must be made obvious. <br />
<pre>totalSum = a + b + c + <br />
d + e; <br />
<br />
method( param1, param2,<br />
param3 ); <br />
<br />
setText( 'Long line split' + <br />
'into two parts.' );<br />
</pre> <br />
=== Whitespace ===<br />
"If" parentheses should be surround by whitespaces.<br />
<pre>if ( true ) return;<br />
NOT<br />
if( true )return;<br />
</pre><br />
Conventional operators should be surrounded by a space (including ternary operators). <br />
<pre>if ( i &gt; 3 &amp;&amp; test == 'yes' )<br />
</pre> <br />
Commas should be followed by a space. <br />
<pre>function myFunction( parm1, param2, param3 )<br />
</pre> <br />
Semi-colons in for statements should be surrounded by a space. <br />
<pre>for ( var i = 0&nbsp;; i &lt; count&nbsp;; i++ )<br />
</pre> <br />
Semi-colons should not be preceded by a space. <br />
<pre>doSomething();<br />
var name = 'John';<br />
</pre> <br />
Colons should be surrounded by a space. <br />
<pre>case 100&nbsp;:<br />
NOT<br />
case 100:<br />
</pre> <br />
Opening parenthesis must be followed by a space and closing parenthesis must be preceded by a space. <br />
<pre>if ( myVar == 1 )<br />
</pre> <br />
There special cases where no space is recommended. When opening parenthesis for a "self-executing anonymous function" and when closing parenthesis after an indented code block:<br />
<pre>(function()<br />
{<br />
// Code here<br />
})();<br />
<br />
myMethod( function()<br />
{<br />
// Code here<br />
});<br />
</pre><br />
Functions/method calls should not be followed by a space. <br />
<pre>doSomething( someParameter );<br />
NOT<br />
doSomething ( someParameter );<br />
</pre> <br />
Logical units within a block should be separated by one blank line. <br />
<pre>// Create a new identity matrix<br />
var matrix = new Matrix4x4();<br />
<br />
// Precompute angles for efficiency <br />
var cosAngle = mathCos( angle );<br />
var sinAngle = mathSin( angle );<br />
<br />
// Specify matrix as a rotation transformation <br />
matrix.setElement( 1, 1, cosAngle );<br />
matrix.setElement( 1, 2, sinAngle ); <br />
matrix.setElement( 2, 1, -sinAngle );<br />
matrix.setElement( 2, 2, cosAngle );<br />
<br />
<br />
// Apply rotation<br />
transformation.multiply( matrix );<br />
</pre><br />
Second line of a multiple variables declarations should have a single tab proceeded.<br />
<pre><br />
var example = 1,<br />
sample = 2;<br />
NOT<br />
var example = 1,<br />
sample = 2;<br />
</pre><br />
<br />
== Variables ==<br />
<br />
Variables must be always defined with "var". <br />
<br />
Function parameters must be in camelCase. <br />
<pre>function sum( firstNumber, secondNumber )<br />
</pre> <br />
Local variables must be in camelCase. <br />
<pre>function doSomething()<br />
{<br />
var colorOne = 1;<br />
var colorTwo = 2;<br />
<br />
return colorOne + colorTwo;<br />
}<br />
</pre> <br />
Several variables can be defined with a single var statement, but only if their initialization values are in single lines. Do not initialize more than one variable is a single line: <br />
<pre>var aVar, someVar,<br />
other1Var = 10,<br />
other2Var = 25,<br />
isVar = true;<br />
<br />
var longVar = function()<br />
{<br />
// This var takes more than one line.<br />
};<br />
<br />
var objVar =<br />
{<br />
// This var takes more than one line.<br />
};<br />
</pre><br />
<br />
== Comments ==<br />
<br />
Tricky code should not be commented but rewritten: In general, the use of comments should be minimized by making the code self-documenting by appropriate name choices and an explicit logical structure. <br />
<br />
All comments should be written in English. Whenever possible, end comments with a period as normal phrases, and wrap comments within the first 80 characters of each line. <br />
<br />
There should be a space after the comment identifier. <br />
<pre>// This is a comment. NOT: //This is a comment <br />
/** NOT: /** <br />
* This is block *This is a block <br />
* comment. *comment <br />
*/ */<br />
</pre> <br />
Note that comment blocks should be opened with two asterisks only for documentation purposes. See [[FCKeditor 3.x/Design and Architecture/Documentation#JavaScript_API|JavaScript API Documentation]].<br />
<br />
== Regular Expressions ==<br />
<br />
The '''regular expression literal''' should be used whenever possible, instead of the RegExp object, which should be used only when the regular expression pattern is not constant or depends on runtime computation.<br />
<pre>/^foo\s*/i<br />
NOT<br />
new RegExp( '^foo\s*', 'i' )<br />
</pre> <br />
Other than shortnesses and better readability, regular expression literals are compiled during script evaluation, which improves performance at runtime.<br />
<br />
== File Headers ==<br />
<br />
There are minimum requirements for us to be able to make our code available to the world. Most of them are related to legal needs, which help us protecting the project from abuses. <br />
<br />
Here is a JavaScript template for the header to be included in the source code: <br />
<pre>/*<br />
Copyright (c) 2003-2009, CKSource - Frederico Knabben. All rights reserved.<br />
For licensing, see LICENSE.html or http://ckeditor.com/license<br />
*/<br />
</pre> <br />
Of course, different languages have different commenting syntax, so it is enough to copy the header from an existing file to maintain the style. <br />
<br />
=== Author Tags ===<br />
<br />
Author names, e-mails or web site addresses should be avoided in the header. To justify that, let me recall a citation from Sander Striker, a member of the Apache Software Foundation, that can be found at [http://producingoss.com/en/managing-volunteers.html#territoriality Producing Open Source Software]: <br />
<blockquote>At the Apache Software foundation we discourage the use of author tags in source code. There are various reasons for this, apart from the legal ramifications. Collaborative development is about working on projects as a group and caring for the project as a group. Giving credit is good, and should be done, but in a way that does not allow for false attribution, even by implication. There is no clear line for when to add or remove an author tag. Do you add your name when you change a comment? When you put in a one-line fix? Do you remove other author tags when you refactor the code and it looks 95% different? What do you do about people who go about touching every file, changing just enough to make the virtual author tag quota, so that their name will be everywhere?<br> </blockquote> <blockquote><br />
There are better ways to give credit, and our preference is to use those. From a technical standpoint author tags are unnecessary; if you wish to find out who wrote a particular piece of code, the version control system can be consulted to figure that out. Author tags also tend to get out of date. Do you really wish to be contacted in private about a piece of code you wrote five years ago and were glad to have forgotten?<br> <br />
</blockquote> <br />
The SVN is a good place to understand user participation. Even when committing changes proposed by Joe White, it is nice to add a comment like "Thanks to Joe White." in the commit message.</div>Garryyaohttps://docs-old.ckeditor.com/index.php?title=FCKeditor_3.x/Design_and_Architecture/Dialog_System&diff=2739FCKeditor 3.x/Design and Architecture/Dialog System2009-11-01T16:49:57Z<p>Garryyao: </p>
<hr />
<div>The new dialog system in CKEditor is to be written from scratch. One of the key things in CKEditor is that it doesn't rely on HTML pages to run. Everything is created on the fly in JavaScript. In this way, we avoid limitations about cross domain serving of the editor code, like CDN solutions, and enhance the editor performance. <br />
<br />
== Framework ==<br />
<br />
Dialogs will be controlled by the Dialog System Framework. This system offer features to define, modify and use dialogs within the editor. It brings uniform design among the dialogs, as well as advanced features with easy. <br />
<br />
== Dialog Manager ==<br />
<br />
The Dialog Manager is the core of the dialog system. It introduces API features to open and manage dialogs in the editor. It also creates the basic structure of the dialog, the dialog framework, and loads the dialog contents. It manages dialog contents validation and provides the features to be used by the dialog definition object. <br />
<br />
== Main API ==<br />
<br />
The dialog system runs under the CKEDITOR.dialog namespace. Its code is to be defined in the "dialog" plugin. <br />
<br />
The dialog plugin extends the CKEDITOR.editor class, by adding the "'''CKEDITOR.editor.openDialog'''" function. This function is relative to the editor instance, because dialogs are sensitive to its configurations, as well as to its contents and selection state. <br />
<br />
== Structure ==<br />
<br />
In a macro structure definition, a dialog is composed by the following pieces: <br />
<br />
*'''Cover''': a semi transparent element which is placed over the entire page to give the user a "modal dialog" effect. The user is required to close the dialog to access the page again.<br />
<br />
*'''Main Dialog Structure''': a floating element that holds the dialog structure. This structure defines several elements that are common to all dialogs:<br><br />
**'''Title''': a title space for the dialog.<br />
**'''Close button''': an element that closes the dialog on click. <br />
**'''Buttons space''': a space reserved to the main dialog buttons, like the "OK" and "Cancel" buttons. <br />
**'''Resize handle''': the element to be used to resize the dialog, if resizable. <br />
**'''Contents''': the space where the dialog contents are to be rendered. <br />
**'''Tabs Space''': the space where dialog tabs are to be rendered. Each tab fills the Contents space with different contents.<br />
<br />
The following is a sample graphical representation of this structure: <br />
<pre>+---------------------------------------+<br />
| (Cover) |<br />
| +---------------------------+ |<br />
| | (Title) (x) | |<br />
| |---------------------------| |<br />
| | (Tabs) | |<br />
| |---------------------------| |<br />
| | (Contents) | |<br />
| | | |<br />
| | | |<br />
| | | |<br />
| | | |<br />
| | | |<br />
| | | |<br />
| |---------------------------| |<br />
| | (Buttons) (/)| |<br />
| +---------------------------+ |<br />
| |<br />
+---------------------------------------+<br />
<br />
(x) = Close button<br />
(/) = Resize handle<br />
</pre> <br />
The main dialog structure is defined by the editor theme, by its "buildDialog" function. This function returns the HTML for the main dialog structure, as well as the information needed by the dialog system to render it properly and fill its "placeholders". <br />
<br />
== Dialog Definition ==<br />
<br />
When opening a dialog, the "Dialog Definition" is to be passed to the dialog system. This definition must be first "registered", to be then called later. The following function can be used to register it: <br />
<pre>CKEDITOR.dialog.add( 'dialog name', function( editor )<br />
{<br />
return { ... definition ... };<br />
) );<br />
<br />
or<br />
<br />
CKEDITOR.dialog.add( 'dialog name', 'definition file path.js' );<br />
</pre> <br />
Note that the definition can either be passed to the dialog system directly, or even be found in a separated JavaScript file. The dialog system will then use a callback system to download the file and load the definition. The definition file should have the add() function call to register the dialog again, just like the first of the above examples. The definitions are then cached and reused by all editor instances. <br />
<br />
The definition is a function that receives an editor instance. This function is called every time a dialog is to be displayed. It then returns the definition object, which may be customized for that specific instance. The following is a compact representation of this object: <br />
<pre>{<br />
title: 'Dialog Title',<br />
<br />
resizable: CKEDITOR.DIALOG_RESIZE_NONE,<br />
<br />
minWidth: {number},<br />
<br />
minHeight: {number},<br />
<br />
buttons: [ ... ],<br />
<br />
contents: [ ... ],<br />
<br />
onOk: function() { ... },<br />
<br />
onCancel: function() { ... },<br />
<br />
onLoad: function( data ) { ... }<br />
}<br />
</pre> <br />
Only the "title" and "contents" properties are required. Other properties have their default values. <br />
<br />
Plugins or user code may at any time change the dialog definition, adding or removing things from it. It is enough to listen for the "dialogDefinition" event in the CKEDITOR object. The definition can also be retrieved at any time after it with the CKEDITOR.dialog.get function. <br />
<br />
Dialogs are not resizable by default. If any of the resize constants are defined (CKEDITOR.DIALOG_RESIZE_HEIGHT | CKEDITOR.DIALOG_RESIZE_WIDHT | CKEDITOR.DIALOG_RESIZE_BOTH), the resize handle will be displayed. The size of the "contents" placeholder is changed when resizing, and the minWidth and minHeight properties are respected. <br />
<br />
The "onOk" and "onCancel" are properties that can be set to functions to be called when one of the standard buttons is clicked. If the function explicitly returns "false", the dialog don't get closed. <br />
<br />
The "onLoad" function is called when the dialog is loaded. An empty "data" object is passed to it. This object may get filled by the function with data to be reused by the dialog elements. <br />
<br />
=== Buttons Definition ===<br />
<br />
By default, the "Cancel" button is available on dialogs. The definition can instead contain a list of buttons to be displayed. The following is an example of the buttons property definition: <br />
<pre>buttons: [<br />
CKEDITOR.dialog.okButton,<br />
<br />
CKEDITOR.dialog.cancelButton,<br />
<br />
{<br />
id: 'unique name',<br />
type: 'button',<br />
label: 'Custom Button',<br />
title: 'Button description',<br />
accessKey: 'C',<br />
disabled: false,<br />
onClick: function()<br />
{<br />
// code on click<br />
},<br />
}<br />
]<br />
</pre> <br />
Note that special objects are available for the "Ok" and "Cancel" buttons. Those objects are actually functions, which accept an object that overrides their default properties. For example, if you want the "Ok" button to be labeled "Go", just do this: <br />
<pre>buttons: [<br />
CKEDITOR.dialog.okButton( {<br />
label: 'Go'<br />
}),<br />
<br />
CKEDITOR.dialog.cancelButton<br />
]<br />
</pre> <br />
The "id" property can be defined on custom buttons. It makes it possible to retrieve a specific button at runtime to execute special functions on it, like enabling/disabling it, or even triggering its click. <br />
<br />
We encourage defining an access key for each custom button. It should be a keyboard keystroke, which will be then combined with the CTRL key. The Ok and Cancel buttons can be fired with the ENTER and ESC key, respectively. <br />
<br />
=== Contents Definition ===<br />
<br />
The "contents" property is the most important in the definition. It defines the actual dialog contents. Note that this property is an array. Each entry in this array is an object. Each object will be represented by a "tab" in the dialog. No tabs are shown if just one object is defined. <br />
<br />
The following is the compact representation of a single contents object: <br />
<pre>{<br />
id: 'unique name',<br />
label: 'Tab Label',<br />
title: 'Contents description',<br />
accessKey: 'Q',<br />
elements&nbsp;: [ ... ]<br />
}<br />
</pre> <br />
Just like the buttons, here again we have id, label, title and access key to be defined for each content object. It is possible to activate one of the tabs by using the CTRL + access key. It is also possible to switching between the tabs by hitting CTRL+SPACE (forward) and CTRL+SHIFT+SPACE (backward). <br />
<br />
The "elements" array contains the UI element definitions for this contents object. Details can be found in the next section. <br />
<br />
== UI Elements ==<br />
<br />
The inner part of the dialog is finally filled with "UI elements". For example, the following is a possible definition for a simple text field: <br />
<pre>{<br />
id: 'width',<br />
type: 'text',<br />
label: editor.lang.width,<br />
title: editor.lang.widthTitle,<br />
default: '120',<br />
className: 'anyClass',<br />
style: 'someStyles',<br />
onLoad: function( data ) { ... }<br />
}<br />
</pre> <br />
Most of the properties are optional, including "id" property, but it is recommended as it makes it easier to customize the dialog. <br />
<br />
The "type" property is required. It indicates which "UI element builder" to use for this element. The dialog core code provides only two element types, "vbox" and "hbox", which are containers for other elements: <br />
<pre>{<br />
type: 'vbox|hbox', <br />
children: [ ... ]<br />
}<br />
</pre> <br />
The "vbox" element will dispose all children elements vertically, one bellow the other. The "hbox" element will place then one next to the other horizontally instead. <br />
<br />
The main contents placeholder itself is rendered by a vbox element object. <br />
<br />
=== Defining Elements ===<br />
<br />
Plugins or inline code can easily define new dialog UI elements to be used inside the dialogs. For that, "UI element builders" must be registered with the following call: <br />
<pre>CKEDITOR.dialog.addUIElement( 'type name', <br />
{ <br />
build&nbsp;: function( elementDefinition, output )<br />
{<br />
// render the element to the output (Array) <br />
<br />
return {<br />
setValue&nbsp;: function( value, resetChanged )<br />
{<br />
// set the element value, based on the elementBag<br />
// information.<br />
},<br />
<br />
getValue&nbsp;: function()<br />
{<br />
// returns the current value.<br />
},<br />
<br />
isChanged&nbsp;: function()<br />
{<br />
// returns a Boolean indicating that the value<br />
// has been changed.<br />
},<br />
<br />
focus&nbsp;: function()<br />
{<br />
}<br />
};<br />
}<br />
});<br />
</pre> <br />
The elementDefinition parameter is the exact element object taken from the dialog definition. If the element handles children elements, it is also responsible for calling the build function for those elements. <br />
<br />
The build function returns an object, which will be used to handle this element at runtime. <br />
<br />
=== Elements Plugin ===<br />
<br />
The editor comes with the "dialogui" plugin, which defines the most common dialog UI elements types: <br />
<pre>{<br />
type&nbsp;: 'text',<br />
label&nbsp;: 'Label Text',<br />
title&nbsp;: 'Field description',<br />
default&nbsp;: '...',<br />
className: '...',<br />
style: '...',<br />
required: true/false,<br />
validate: function() { ... }<br />
}<br />
<br />
{<br />
type&nbsp;: 'select',<br />
label&nbsp;: 'Label Text',<br />
title&nbsp;: 'Field description',<br />
default&nbsp;: '...',<br />
className: '...',<br />
style: '...',<br />
required: true/false,<br />
validate: function() { ... }<br />
items:<br />
[<br />
[ 'Label 1', 'Value' ],<br />
[ 'Label 2' ] // Value is 'Label 2'<br />
]<br />
}<br />
<br />
{<br />
type&nbsp;: 'radio',<br />
label&nbsp;: 'Label Text',<br />
title&nbsp;: 'Field description',<br />
default&nbsp;: '...',<br />
className: '...',<br />
style: '...',<br />
required: true/false,<br />
validate: function() { ... },<br />
items:<br />
[<br />
[ 'Label 1', 'Value', 'Title' ],<br />
[ 'Label 2' ] // Value and Title are 'Label 2'<br />
]<br />
}<br />
<br />
{<br />
type&nbsp;: 'checkbox',<br />
label&nbsp;: 'Label Text',<br />
title&nbsp;: 'Field description',<br />
checked&nbsp;: true|false,<br />
className: '...',<br />
style: '...',<br />
required: true/false,<br />
validate: function() { ... }<br />
}<br />
<br />
{<br />
type&nbsp;: 'button',<br />
label&nbsp;: 'Label Text',<br />
title&nbsp;: 'Field description',<br />
className: '...',<br />
style: '...',<br />
onClick&nbsp;: function(){ ... }<br />
}<br />
<br />
{<br />
type&nbsp;: 'html',<br />
className: '...',<br />
style: '...',<br />
html: 'Some &lt;b&gt;HTML&lt;/b&gt;'<br />
}<br />
<br />
</pre> <br />
== Workflow ==<br />
<br />
When loading the dialog: <br />
<br />
*editor.openDialog( 'dialogName' ) is called. <br />
*The dialog system shows the cover (hourglass icon). <br />
*The dialog definition for 'dialogName' is loaded. <br />
*If needed, the dialog definition is downloaded. <br />
*editor.theme.buildDialog() is called returning the main structure HTML <br />
*The main structure HTML is injected into the DOM (hidden). <br />
*Based on the dialog definition, the dialog system fills the dialog title, enables the resize handler and creates the dialog buttons. <br />
*The "onLoad" function is called for the dialog definition. <br />
*Tabs are created for the content objects. <br />
*The "onLoad" is called for each UI elements defined (recursively on children elements also). <br />
*All elements in the content object to be displayed are rendered. <br />
*The resulting rendered HTML is injected into the DOM. <br />
*The dialog is displayed (normal icon).<br />
<br />
When hitting Ok: <br />
<br />
*The "validate" function is called for each element. If any of them is invalid, the focus is moved to it, and a standard UI alert is displayed. <br />
*The "onOk" function is called. <br />
*If "onOk" doesn't return "false", the dialog gets destroyed.<br />
<br />
When hitting Cancel: <br />
<br />
*The "isChanged" function is called for each element. If any of then has been changed, a standard warning message is displayed ("Are you sure blah blah...?"). <br />
*The "onCancel" function is called. <br />
*If "onCancel" doesn't return "false", the dialog gets destroyed.<br />
<br />
== Dialog Definition API Extensions ==<br />
<br />
Once registered, a dialog definition gets "extended" by the dialog system. A few API functions are added to it, making it possible to manipulate it: <br />
<br />
*getContents( 'id' ): gets a specific contents object, by id. <br />
*getButton( 'id' ): gets a specific button object, by id. <br />
*addContents( { ... contents object } [, nextSiblingId] ): adds a content object to the definitions. If the second parameter is specify, the added object is placed before the object with that id, otherwise it is appended to the end. <br />
*addButton( { ... button object } [,nextSiblingId] ): the same exact behavior of addContents, but for the buttons. <br />
*removeContents( 'id' ): removes one of the contents objects. <br />
*removeButton( 'id' ): removes one of the buttons.<br />
<br />
Contents objects are extended with the following functions: <br />
<br />
*get( 'id' ): gets one of the UI elements by id. <br />
*add( { ... element definition } [,nextSiblingId] ): just like addContents, it adds UI elements to the list. <br />
*remove( 'id' ): removes one of the UI elements.<br />
<br />
Button object are extended with the following functions: <br />
<br />
*enable(): enables the button. <br />
*disable(): disables the button.</div>Garryyaohttps://docs-old.ckeditor.com/index.php?title=CKTester/&diff=2701CKTester/2009-09-25T09:48:30Z<p>Garryyao: New page: *User's Guide *Test Runners</p>
<hr />
<div>*[[CKTester/Users_Guide|User's Guide]] <br />
*[[CKTester/Runners|Test Runners]]</div>Garryyaohttps://docs-old.ckeditor.com/index.php?title=CKTester/Runners&diff=2700CKTester/Runners2009-09-25T09:45:49Z<p>Garryyao: </p>
<hr />
<div>== Overview ==<br />
'''Test runners''' are JavaScript testing frameworks used in the [[CKTester/Users_Guide#Test_Cell|cells]], which are deployed under '/runners' folder of the CKTester project. Currently the following runners are supported:<br />
# [http://developer.yahoo.com/yui/yuitest/ YUI Unit Test]<br />
# [[CKTester/ManualTestRunner|CKTester Manual Runner]]<br />
<br />
== Runner Extension ==<br />
Sometimes runner doesn't work with CKTester naturally( e.g. YUI Unit Test ), the integration efforts are delivered as extensions scripts which will enhance/integrate the runner at run time.</div>Garryyaohttps://docs-old.ckeditor.com/index.php?title=CKTester/Runners&diff=2699CKTester/Runners2009-09-25T09:44:01Z<p>Garryyao: New page: == Overview == Runners are JavaScript testing frameworks used in the cells, which are deployed under '/runners' folder of the CKTester project. Currently the foll...</p>
<hr />
<div>== Overview ==<br />
Runners are JavaScript testing frameworks used in the [[Users_Guide#Test_Cell|cells]], which are deployed under '/runners' folder of the CKTester project. Currently the following runners are supported:<br />
# [http://developer.yahoo.com/yui/yuitest/ YUI Unit Test]<br />
# [[CKTester/ManualTestRunner|CKTester Manual Runner]]<br />
<br />
== Runner Extension ==<br />
Sometimes the runner doesn't work with CKTester naturally( e.g. YUI Unit Test ), the integration efforts are delivered as extensions scripts which will enhance/integrate the runner at run time.</div>Garryyaohttps://docs-old.ckeditor.com/index.php?title=CKTester/ManualTestRunner&diff=2698CKTester/ManualTestRunner2009-09-25T09:31:36Z<p>Garryyao: </p>
<hr />
<div>== Overview ==<br />
<br />
The '''manual testing runner''' is one type of our internal runners which dedicate to functional testing that are impossible to deliver with automation. It's designed to help developers/reports authoring and viewing manual testing scripts with ease, and with the ability to seamlessly integrate with [[CKTester/Users Guide|CKTester]].<br />
<br />
== Cell Config<br> ==<br />
<br />
In order to have the cell been indentified as a manual testing case, the [[CKTester/Users Guide#Tags|tag]] ''''manual'''' is required.<br />
<br />
== Script Authoring ==<br />
<br />
You could write the manual testing procedures( scripts ) in your preferred language, currently the following language are supported: <br />
<br />
=== Trac Wiki ===<br />
<br />
Write the scripts inside a &lt;pre&gt; tag at the beginning of doc body indicate the '''TracWiki format''' is under use: <br />
<pre>&lt;body&gt;<br />
&lt;pre&gt;<br />
=== TC 1 ===<br />
1. Step1;<br />
1. Step2;<br />
1. Step3;<br />
* Expected Result: The output codes of editor should be:<br />
{{{<br />
Output data...<br />
}}}<br />
* Actual Result: JavaScript error thrown.<br />
&lt;/pre&gt;<br />
&lt;/body&gt;<br />
</pre> <br />
=== HTML ===<br />
<br />
Write the scripts inside a &lt;div&gt; tag at the beginning of doc body indicate the '''HTML''' is under use: <br />
<pre>&lt;body&gt;<br />
&lt;div&gt;<br />
&lt;ol&gt;<br />
&lt;li&gt;Step1;&lt;/li&gt;<br />
&lt;li&gt;Step2;&lt;/li&gt;<br />
&lt;li&gt;Step3;&lt;/li&gt;<br />
&lt;/ol&gt;<br />
&lt;ul&gt;<br />
&lt;li&gt;Expected Result: The output codes of editor should be:<br />
&lt;pre&gt;<br />
Output data...<br />
&lt;/pre&gt;<br />
&lt;/li&gt;<br />
&lt;li&gt;Actual Result: JavaScript error thrown.&lt;/li&gt;<br />
&lt;/ul&gt;<br />
&lt;/div&gt;<br />
&lt;/body&gt;<br />
</pre> <br />
== Common Tasks ==<br />
<br />
=== Test Decision ===<br />
<br />
The most important step is to give a judgment to the test's final result after reproducing the procedures. A ''''PASS'''' button along with a <span style="font-weight: bold;">'</span>'''FAIL'''' button are provided to achieve this, once the decision is made, the cell will be closed and result are report to the [[CKTester/Users_Guide#Fort|fort]].</div>Garryyaohttps://docs-old.ckeditor.com/index.php?title=CKTester/ManualTestRunner&diff=2697CKTester/ManualTestRunner2009-09-25T09:30:57Z<p>Garryyao: </p>
<hr />
<div>== Overview ==<br />
<br />
The '''manual testing runner''' is one type of our internal runners which dedicate to functional testing that are impossible to deliver with automation. It's designed to help developers/reports authoring and viewing manual testing scripts with ease, and with the ability to seamlessly integrate with [[CKTester/Users Guide|CKTester]].<br />
<br />
== Cell Config<br> ==<br />
<br />
In order to have the cell been indentified as a manual testing case, the [[CKTester/Users Guide#Tags|tag]]''''manual'''' is required.<br />
<br />
== Script Authoring ==<br />
<br />
You could write the manual testing procedures( scripts ) in your preferred language, currently the following language are supported: <br />
<br />
=== Trac Wiki ===<br />
<br />
Write the scripts inside a &lt;pre&gt; tag at the beginning of doc body indicate the '''TracWiki format''' is under use: <br />
<pre>&lt;body&gt;<br />
&lt;pre&gt;<br />
=== TC 1 ===<br />
1. Step1;<br />
1. Step2;<br />
1. Step3;<br />
* Expected Result: The output codes of editor should be:<br />
{{{<br />
Output data...<br />
}}}<br />
* Actual Result: JavaScript error thrown.<br />
&lt;/pre&gt;<br />
&lt;/body&gt;<br />
</pre> <br />
=== HTML ===<br />
<br />
Write the scripts inside a &lt;div&gt; tag at the beginning of doc body indicate the '''HTML''' is under use: <br />
<pre>&lt;body&gt;<br />
&lt;div&gt;<br />
&lt;ol&gt;<br />
&lt;li&gt;Step1;&lt;/li&gt;<br />
&lt;li&gt;Step2;&lt;/li&gt;<br />
&lt;li&gt;Step3;&lt;/li&gt;<br />
&lt;/ol&gt;<br />
&lt;ul&gt;<br />
&lt;li&gt;Expected Result: The output codes of editor should be:<br />
&lt;pre&gt;<br />
Output data...<br />
&lt;/pre&gt;<br />
&lt;/li&gt;<br />
&lt;li&gt;Actual Result: JavaScript error thrown.&lt;/li&gt;<br />
&lt;/ul&gt;<br />
&lt;/div&gt;<br />
&lt;/body&gt;<br />
</pre> <br />
== Common Tasks ==<br />
<br />
=== Test Decision ===<br />
<br />
The most important step is to give a judgment to the test's final result after reproducing the procedures. A ''''PASS'''' button along with a <span style="font-weight: bold;">'</span>'''FAIL'''' button are provided to achieve this, once the decision is made, the cell will be closed and result are report to the [[http://docs.fckeditor.net/CKTester/Users_Guide#Fort|fort]].</div>Garryyaohttps://docs-old.ckeditor.com/index.php?title=CKTester/ManualTestRunner&diff=2696CKTester/ManualTestRunner2009-09-25T09:27:55Z<p>Garryyao: </p>
<hr />
<div>== Overview ==<br />
<br />
The '''manual testing runner''' is one type of our internal runners which dedicate to functional testing that are impossible to deliver with automation. It's designed to help developers/reports authoring and viewing manual testing scripts with ease, and with the ability to seamlessly integrate with CKTester. <br />
<br />
== Cell Config<br> ==<br />
<br />
In order to have the cell been indentified as a manual testing case, the tag ''''manual'''' is required. ( [[CKTester/Users_Guide#Tags|What's a tag?]] )<br />
<br />
== Script Authoring ==<br />
<br />
You could write the manual testing procedures( scripts ) in your preferred language, currently the following language are supported: <br />
<br />
=== Trac Wiki ===<br />
<br />
Write the scripts inside a &lt;pre&gt; tag at the beginning of doc body indicate the '''TracWiki format''' is under use: <br />
<pre>&lt;body&gt;<br />
&lt;pre&gt;<br />
=== TC 1 ===<br />
1. Step1;<br />
1. Step2;<br />
1. Step3;<br />
* Expected Result: The output codes of editor should be:<br />
{{{<br />
Output data...<br />
}}}<br />
* Actual Result: JavaScript error thrown.<br />
&lt;/pre&gt;<br />
&lt;/body&gt;<br />
</pre> <br />
=== HTML ===<br />
<br />
Write the scripts inside a &lt;div&gt; tag at the beginning of doc body indicate the '''HTML''' is under use: <br />
<pre>&lt;body&gt;<br />
&lt;div&gt;<br />
&lt;ol&gt;<br />
&lt;li&gt;Step1;&lt;/li&gt;<br />
&lt;li&gt;Step2;&lt;/li&gt;<br />
&lt;li&gt;Step3;&lt;/li&gt;<br />
&lt;/ol&gt;<br />
&lt;ul&gt;<br />
&lt;li&gt;Expected Result: The output codes of editor should be:<br />
&lt;pre&gt;<br />
Output data...<br />
&lt;/pre&gt;<br />
&lt;/li&gt;<br />
&lt;li&gt;Actual Result: JavaScript error thrown.&lt;/li&gt;<br />
&lt;/ul&gt;<br />
&lt;/div&gt;<br />
&lt;/body&gt;<br />
</pre> <br />
== Common Tasks ==<br />
<br />
=== Test Decision ===<br />
<br />
The most important step is to give a judgment to the test's final result after reproducing the procedures. A ''''PASS'''' button along with a <span style="font-weight: bold;">'</span>'''FAIL'''' button are provided to achieve this.</div>Garryyaohttps://docs-old.ckeditor.com/index.php?title=CKTester/ManualTestRunner&diff=2695CKTester/ManualTestRunner2009-09-25T09:22:22Z<p>Garryyao: </p>
<hr />
<div>== Overview ==<br />
<br />
The manual testing runner is one type of our internal runners which dedicate to functional testing that are impossible to deliver with automation. It's designed to help developers/reports authoring and viewing manual testing scripts with ease, and with the ability to seamlessly integrate with CKTester. <br />
<br />
<br> <br />
<br />
== Script Authoring ==<br />
<br />
You could write the manual testing procedures( scripts ) in your preferred language, currently the following language are supported: <br />
<br />
=== Trac Wiki ===<br />
<br />
Write the scripts inside a &lt;pre&gt; tag at the beginning of doc body indicate the '''TracWiki format''' is under use: <br />
<pre>&lt;body&gt;<br />
&lt;pre&gt;<br />
=== TC 1 ===<br />
1. Step1;<br />
1. Step2;<br />
1. Step3;<br />
* Expected Result: The output codes of editor should be:<br />
{{{<br />
Output data...<br />
}}}<br />
* Actual Result: JavaScript error thrown.<br />
&lt;/pre&gt;<br />
&lt;/body&gt;<br />
</pre> <br />
=== HTML ===<br />
<br />
Write the scripts inside a &lt;div&gt; tag at the beginning of doc body indicate the '''HTML''' is under use: <br />
<pre>&lt;body&gt;<br />
&lt;div&gt;<br />
&lt;ol&gt;<br />
&lt;li&gt;Step1;&lt;/li&gt;<br />
&lt;li&gt;Step2;&lt;/li&gt;<br />
&lt;li&gt;Step3;&lt;/li&gt;<br />
&lt;/ol&gt;<br />
&lt;ul&gt;<br />
&lt;li&gt;Expected Result: The output codes of editor should be:<br />
&lt;pre&gt;<br />
Output data...<br />
&lt;/pre&gt;<br />
&lt;/li&gt;<br />
&lt;li&gt;Actual Result: JavaScript error thrown.&lt;/li&gt;<br />
&lt;/ul&gt;<br />
&lt;/div&gt;<br />
&lt;/body&gt;<br />
</pre> <br />
== Common Tasks ==<br />
<br />
=== Test Decision ===<br />
<br />
The most important step is to give a judgment to the test's final result after reproducing the procedures. A ''''PASS'''' button along with a <span style="font-weight: bold;">'</span>'''FAIL'''' button are provided to achieve this.</div>Garryyaohttps://docs-old.ckeditor.com/index.php?title=CKTester/ManualTestRunner&diff=2694CKTester/ManualTestRunner2009-09-25T09:04:02Z<p>Garryyao: New page: == Overview == The manual testing runner is one type of our internal runners which dedicate to functional testing that are impossible to deliver with automation. It's designed to help de...</p>
<hr />
<div>== Overview ==<br />
<br />
The manual testing runner is one type of our internal runners which dedicate to functional testing that are impossible to deliver with automation. It's designed to help developers/reports authoring and viewing manual testing scripts with ease, and with the ability to seamlessly integrate with CKTester. <br />
<br />
<br> <br />
<br />
== Script Authoring ==<br />
<br />
You could write the manual testing procedures( scripts ) in your preferred language, currently the following language are supported: <br />
<br />
=== Trac Wiki ===<br />
<br />
Write the scripts inside a &lt;pre&gt; tag at the beginning of doc body indicate the Trac Wiki is under use:<br />
<pre><br />
</pre><br />
HTML<br />
<br />
Write the scripts inside a &lt;div&gt; tag at the beginning of doc body indicate the HTML is under use: <br />
<pre><br />
</pre></div>Garryyaohttps://docs-old.ckeditor.com/index.php?title=CKTester/Users_Guide&diff=2693CKTester/Users Guide2009-09-24T09:25:36Z<p>Garryyao: </p>
<hr />
<div>== Overview ==<br />
<br />
'''CKTester''' is our internal testing hub, created to provide seamless and integrated testing experience to our developers, been capable of managing and interfacing tests from various projects which may potentially rely on different testing frameworks/runners. Been designed with convenient authoring and ease of viewing the test cases in mind, it could be running independently in all situation from a browser&nbsp;: locally, on a web server or via secure connections. <br />
<br />
== How It Works ==<br />
It would be easy to understand how the system works by looking at each of the following components which constitute it.<br />
<br />
=== Test Cell ===<br />
<br />
A '''test cell''' is the basic unit of a project's testing, a plain HTML file reside in individual project's testing sources, in which test suites/cases are written. It will be loaded and executed inside an iframe or popup window depends on the running of choice, so '''full page life cycle''' ( from page load to page destroy ) is guaranteed.<br><br />
<br />
Each cell has one key responsibility of '''reporting''' the sucess/failure/time of it's execution to the fort, this is done by cross-frame communication with parent/opener window. For this, the cell is required to include a bootstrap file: <br />
<pre>&lt;script type="text/javascript" src="{CKTester_ROOT}/bootstrap.js"&gt;&lt;/script&gt;<br />
</pre> <br />
The cell's entire testing environment, including testing target, runtime libraries, etc. will mostly be injected by the fort, which are declared by a meta tag of the HTML file. This inversion of control feature (IoC) make the cell testing framework neutral.<br><br />
<pre>// I'm a unit test for the editor(CKEditor) and the TCs within me are stable( been finalized ). <br />
&lt;meta name="tags" content="editor,unit,stable"&gt;<br />
</pre><br />
=== Profile ===<br />
<br />
A '''testing profile''' is a JavaScript configuration file which specify how a project is to be tested by CKTester. It contains a function which returns a configuration object including.&nbsp;<br> <br />
<br />
#'''Cells list'''&nbsp;: A list of key/values which tells where are the cells and what are the tags of each cell.<br>Key&nbsp;: The test cell '''file path''', where all the paths are relative to the runner; <br>Value&nbsp;: An array of '''tags''' of that cell.<br><br />
<br />
#'''Cell Resolvers&nbsp;''': An array of functions which were used to manipulate each cell's attributes, e.g. Inject necessary dependencies for cells which have certain tags. These are the complementary of the default resolvers that the '''fort '''already has.<br><br />
<br />
The file content will basically looks like: <br />
<pre>CKTester.profile = function ()<br />
{<br />
return<br />
{<br />
cells&nbsp;: [<br />
[ '/dt/unit/plugins/htmldataprocessor/1' ], // Implicit tag declaration( each sub path form a tag ).<br />
[ '/tt/1.html' , [ 'editor', 'unit', 'htmldataprocessor' ] ] // Explicit tag declaration.<br />
]<br />
cellResolvers&nbsp;:<br />
[<br />
function( cell )<br />
{<br />
var tags = cell.tags, env = cell.environment;<br />
<br />
// Inject CKEditor source.<br />
if( ( tags.indexOf( 'editor' )&nbsp;!= -1 )<br />
&amp;&amp; ( tags.indexOf( 'editor-ondemand' ) == -1 ) )<br />
env.push( '${CKEDITOR_ROOT}/ckeditor_source.js' );<br />
else if ( tags.indexOf( 'editor-ondemand' ) )<br />
env.push( '${CKEDITOR_ROOT}/ckeditor_basic_source.js' );<br />
<br />
// Inject CKEditor unit test library.<br />
if ( tags.indexOf( 'unit' )&nbsp;!= -1 )<br />
env.push( '${CKEDITOR_TEST_BRANCH_ROOT}/js/unit.js' );<br />
<br />
// Inject CKEditor manual test library.<br />
if ( tags.indexOf( 'manual' )&nbsp;!= -1 )<br />
env.push( '${CKEDITOR_TEST_BRANCH_ROOT}/js/manual.js' );<br />
}<br />
]<br />
};<br />
}<br />
</pre> <br />
'''Note''': the testing profile is recommanded to be generated automatically by the gen-profile tool script, though it could be altered manually.<br> <br />
<br />
=== Tags ===<br />
<br />
'''Tag''' is playing an important role as the '''annotation '''of a cell with the following aspects: <br />
<br />
#Environments( dependencies ) of a cell, e.g. if the cell has tags 'unit' and 'editor', it denote it must be running under a unit test runner( e.g. YUITest ), and the testing target is CKEditor; <br />
#Categories of the cell, useful to grouping similar cells. E.g. A cell with a path 'dt/core/dom/documentfragment' denote it's a design test for the core codes of dom module about document-fragment. <br />
#Any other reasonable denotation.<br />
<br />
=== Fort ===<br />
<br />
The '''Test Fort''' is a central hub for registering and running all the cells, which also consists of a UI to specifiy criterias and viewing report. <br />
<br />
The runner is driven by a specified profile( use the default one if not specified ), from which all cells are registering. Upon requesting by a specific testing criteria, it filtering down the registered cells to only execute the satisfied ones. <br />
<br />
During the loading of each cell before running, an extensible '''cell resolver''' will manipulate ( to figure out the required/requested resources of a specific cell ) the cell by analysing it's tags, guarantee the cell always has all the environment it should receive. These resources are typically composed of&nbsp;: <br />
<br />
*The testing target <br />
*The testing library <br />
*Any resources dedicated to the cell.<br><br />
<br />
At last the cell will be running in one of these '''two modes''' depend on the user: <br />
<br />
#Managed Mode&nbsp;: It's the default mode when it's running in a batch of cells by the forge, where the cell is running in an iframe. <br />
#Standalone Mode&nbsp;: When a cell is running separately, on the opposite of 'Managed Mode', the cell will be running inside a popup window, this is often used when it's a manual test case or detailed information about the TCs is required to be reviewed( e.g. which exactly test method failed in the TC? ).<br />
<br />
=== Testing Criteria ===<br />
<br />
A criteria is simply a URL request to the fort, tells which cells to be run. <br />
<br />
#It could contains a path to a '''profile''' to be used. <br />
#It could contains certain tags, so only with which the cells to be run. <br />
#It could explicitly specify a single cell location along with certain tags.<br />
<br />
Some example criteria look like: <br />
<br />
*Running all cells defined in a specified profile file: http://ckeditor.t/cktester/fort.html?profile=../myprofile.js <br />
*Running all the stable unit tests of the default profile: http://ckeditor.t/cktester/fort.html?cells=stable,unit <br />
*Running a specific ticket test with tags 'editor','unit','all'&nbsp;: http://ckeditor.t/cktester/fort.html?cells=http://ckeditor.t/tt/4397/1.html&amp;tags=editor,unit,all<br>( '''Note''': It's a shortcut to achieved the same criteria by just open the url of that individual cell (http://ckeditor.t/tt/4397/1.html) and it will be redirected correctly back to the forge. )<br><br />
<br />
== Installation ==<br />
<br />
'''Note''': Below we'll take the CKEditor project as an example to illustrate the install process. <br />
<br />
<br> First of all, checking out these three component: the staging project, it's test suites and CKTester eventually. <br />
<br />
#Checkout CKEditor's testing branch from [http://svn.fckeditor.net/CKEditor/tests SVN] ( We name the working copy path as CKEDITOR_TEST_ROOT below ). <br> <br />
#Checkout CKEditor trunk( or any other version are subjected to test ) from [http://svn.fckeditor.net/CKEditor/trunk/ SVN] into a folder ( e.g. ckeditor ) under CKEDITOR_TEST_ROOT ( We name the working copy path as CKEDITOR_ROOT below ).<br> <br />
#Checkout CKTester from [http://svn.fckeditor.net/CKTester SVN]&nbsp;into a folder( e.g. cktester ) under CKEDITOR_TEST_ROOT( We name the working copy path as CKTESTER_ROOT below ).<br />
<br />
Open the file {CKTESTER_ROOT}/variables.js.tpl with modification to the following variables:<br> <br />
<pre> // Absolute path point to the root path of CKEditor project.<br />
'CKEDITOR_ROOT'&nbsp;: '/ckeditor',<br />
<br />
// Point to the root path of CKEditor test branch.<br />
( You don't need to alter it if your web server's serving root from CKEDITOR_TEST_ROOT.<br />
'CKEDITOR_TEST_BRANCH_ROOT'&nbsp;: '/'<br />
</pre> <br />
At last, run the script {CKTESTER_ROOT}/_dev/gen-profile.bat(.sh) ( you'll need install [http://ant.apache.org/ Apache Ant and configure the ANT_HOME variable of your system ] ) which helps you to generate the testing profile automatically by scanning the resources within {CKEDITOR_TEST_ROOT}. After that, you should get a file created at {CKTESTER_ROOT}/profile.js.<br />
<br />
And it's done, now point your web browser at {CKEDITOR_TEST_ROOT}/index.html, there're already a few pilot links which help you to kick start.<br> <br />
<br />
<br><br />
<br />
== Common Tasks ==<br />
<br />
'''Note''': All the following tasks are assuming you already have CKTester properly installed.<br> <br />
<br />
=== Running a specific ticket test ===<br />
<br />
It's quite a frequent usecase when you're working on a particular ticket and quite straight forward that you can just point the browser to the location of that ticket test cell(e.g. [http://ckeditor.t/tt/4385/1.html http://ckeditor.t/tt/4385/1.html]), CKTester will redirect you to the fort as single cell criteria.<br />
<br />
== History ==<br />
<br />
CKTester is evolved from previous project '''FCKTest'''. <br />
<br />
<br></div>Garryyaohttps://docs-old.ckeditor.com/index.php?title=CKTester/Users_Guide&diff=2692CKTester/Users Guide2009-09-24T09:18:15Z<p>Garryyao: /* Installation */</p>
<hr />
<div>== Overview ==<br />
<br />
'''CKTester''' is our internal testing hub, created to provide seamless and integrated testing experience to our developers, been capable of managing and interfacing tests from various projects which may potentially rely on different testing frameworks/runners. Been designed with convenient authoring and ease of viewing the test cases in mind, it could be running independently in all situation from a browser&nbsp;: locally, on a web server or via secure connections. <br />
<br />
== How It Works ==<br />
<br />
=== Test Cell ===<br />
<br />
A '''test cell''' is the basic unit of a project's testing, a plain HTML file reside in individual project's testing sources, in which test suites/cases are written. It will be loaded and executed inside an iframe or popup window depends on the running of choice, so '''full page life cycle''' ( from page load to page destroy ) is guaranteed.<br><br />
<br />
Each cell has one key responsibility of '''reporting''' the sucess/failure/time of it's execution to the fort, this is done by cross-frame communication with parent/opener window. For this, the cell is required to include a bootstrap file: <br />
<pre>&lt;script type="text/javascript" src="{CKTester_ROOT}/bootstrap.js"&gt;&lt;/script&gt;<br />
</pre> <br />
The cell's entire testing environment, including testing target, runtime libraries, etc. will mostly be injected by the fort, which are declared by a meta tag of the HTML file. This inversion of control feature (IoC) make the cell testing framework neutral.<br><br />
<pre>// I'm a unit test for the editor(CKEditor) and the TCs within me are stable( been finalized ). <br />
&lt;meta name="tags" content="editor,unit,stable"&gt;<br />
</pre><br />
=== Profile ===<br />
<br />
A '''testing profile''' is a JavaScript configuration file which specify how a project is to be tested by CKTester. It contains a function which returns a configuration object including.&nbsp;<br> <br />
<br />
#'''Cells list'''&nbsp;: A list of key/values which tells where are the cells and what are the tags of each cell.<br>Key&nbsp;: The test cell '''file path''', where all the paths are relative to the runner; <br>Value&nbsp;: An array of '''tags''' of that cell.<br><br />
<br />
#'''Cell Resolvers&nbsp;''': An array of functions which were used to manipulate each cell's attributes, e.g. Inject necessary dependencies for cells which have certain tags. These are the complementary of the default resolvers that the '''fort '''already has.<br><br />
<br />
The file content will basically looks like: <br />
<pre>CKTester.profile = function ()<br />
{<br />
return<br />
{<br />
cells&nbsp;: [<br />
[ '/dt/unit/plugins/htmldataprocessor/1' ], // Implicit tag declaration( each sub path form a tag ).<br />
[ '/tt/1.html' , [ 'editor', 'unit', 'htmldataprocessor' ] ] // Explicit tag declaration.<br />
]<br />
cellResolvers&nbsp;:<br />
[<br />
function( cell )<br />
{<br />
var tags = cell.tags, env = cell.environment;<br />
<br />
// Inject CKEditor source.<br />
if( ( tags.indexOf( 'editor' )&nbsp;!= -1 )<br />
&amp;&amp; ( tags.indexOf( 'editor-ondemand' ) == -1 ) )<br />
env.push( '${CKEDITOR_ROOT}/ckeditor_source.js' );<br />
else if ( tags.indexOf( 'editor-ondemand' ) )<br />
env.push( '${CKEDITOR_ROOT}/ckeditor_basic_source.js' );<br />
<br />
// Inject CKEditor unit test library.<br />
if ( tags.indexOf( 'unit' )&nbsp;!= -1 )<br />
env.push( '${CKEDITOR_TEST_BRANCH_ROOT}/js/unit.js' );<br />
<br />
// Inject CKEditor manual test library.<br />
if ( tags.indexOf( 'manual' )&nbsp;!= -1 )<br />
env.push( '${CKEDITOR_TEST_BRANCH_ROOT}/js/manual.js' );<br />
}<br />
]<br />
};<br />
}<br />
</pre> <br />
'''Note''': the testing profile is recommanded to be generated automatically by the gen-profile tool script, though it could be altered manually.<br> <br />
<br />
=== Tags ===<br />
<br />
'''Tag''' is playing an important role as the '''annotation '''of a cell with the following aspects: <br />
<br />
#Environments( dependencies ) of a cell, e.g. if the cell has tags 'unit' and 'editor', it denote it must be running under a unit test runner( e.g. YUITest ), and the testing target is CKEditor; <br />
#Categories of the cell, useful to grouping similar cells. E.g. A cell with a path 'dt/core/dom/documentfragment' denote it's a design test for the core codes of dom module about document-fragment. <br />
#Any other reasonable denotation.<br />
<br />
=== Fort ===<br />
<br />
The '''Test Fort''' is a central hub for registering and running all the cells, which also consists of a UI to specifiy criterias and viewing report. <br />
<br />
The runner is driven by a specified profile( use the default one if not specified ), from which all cells are registering. Upon requesting by a specific testing criteria, it filtering down the registered cells to only execute the satisfied ones. <br />
<br />
During the loading of each cell before running, an extensible '''cell resolver''' will manipulate ( to figure out the required/requested resources of a specific cell ) the cell by analysing it's tags, guarantee the cell always has all the environment it should receive. These resources are typically composed of&nbsp;: <br />
<br />
*The testing target <br />
*The testing library <br />
*Any resources dedicated to the cell.<br><br />
<br />
At last the cell will be running in one of these '''two modes''' depend on the user: <br />
<br />
#Managed Mode&nbsp;: It's the default mode when it's running in a batch of cells by the forge, where the cell is running in an iframe. <br />
#Standalone Mode&nbsp;: When a cell is running separately, on the opposite of 'Managed Mode', the cell will be running inside a popup window, this is often used when it's a manual test case or detailed information about the TCs is required to be reviewed( e.g. which exactly test method failed in the TC? ).<br />
<br />
=== Testing Criteria ===<br />
<br />
A criteria is simply a URL request to the fort, tells which cells to be run. <br />
<br />
#It could contains a path to a '''profile''' to be used. <br />
#It could contains certain tags, so only with which the cells to be run. <br />
#It could explicitly specify a single cell location along with certain tags.<br />
<br />
Some example criteria look like: <br />
<br />
*Running all cells defined in a specified profile file: http://ckeditor.t/cktester/fort.html?profile=../myprofile.js <br />
*Running all the stable unit tests of the default profile: http://ckeditor.t/cktester/fort.html?cells=stable,unit <br />
*Running a specific ticket test with tags 'editor','unit','all'&nbsp;: http://ckeditor.t/cktester/fort.html?cells=http://ckeditor.t/tt/4397/1.html&amp;tags=editor,unit,all<br>( '''Note''': It's a shortcut to achieved the same criteria by just open the url of that individual cell (http://ckeditor.t/tt/4397/1.html) and it will be redirected correctly back to the forge. )<br><br />
<br />
== Installation ==<br />
<br />
'''Note''': Below we'll take the CKEditor project as an example to illustrate the install process. <br />
<br />
<br> First of all, checking out these three component: the staging project, it's test suites and CKTester eventually. <br />
<br />
#Checkout CKEditor's testing branch from [http://svn.fckeditor.net/CKEditor/tests SVN] ( We name the working copy path as CKEDITOR_TEST_ROOT below ). <br> <br />
#Checkout CKEditor trunk( or any other version are subjected to test ) from [http://svn.fckeditor.net/CKEditor/trunk/ SVN] into a folder ( e.g. ckeditor ) under CKEDITOR_TEST_ROOT ( We name the working copy path as CKEDITOR_ROOT below ).<br> <br />
#Checkout CKTester from [http://svn.fckeditor.net/CKTester SVN]&nbsp;into a folder( e.g. cktester ) under CKEDITOR_TEST_ROOT( We name the working copy path as CKTESTER_ROOT below ).<br />
<br />
Open the file {CKTESTER_ROOT}/variables.js.tpl with modification to the following variables:<br> <br />
<pre> // Absolute path point to the root path of CKEditor project.<br />
'CKEDITOR_ROOT'&nbsp;: '/ckeditor',<br />
<br />
// Point to the root path of CKEditor test branch.<br />
( You don't need to alter it if your web server's serving root from CKEDITOR_TEST_ROOT.<br />
'CKEDITOR_TEST_BRANCH_ROOT'&nbsp;: '/'<br />
</pre> <br />
At last, run the script {CKTESTER_ROOT}/_dev/gen-profile.bat(.sh) ( you'll need install [http://ant.apache.org/ Apache Ant and configure the ANT_HOME variable of your system ] ) which helps you to generate the testing profile automatically by scanning the resources within {CKEDITOR_TEST_ROOT}. After that, you should get a file created at {CKTESTER_ROOT}/profile.js.<br />
<br />
And it's done, now point your web browser at {CKEDITOR_TEST_ROOT}/index.html, there're already a few pilot links which help you to kick start.<br> <br />
<br />
<br><br />
<br />
== Common Tasks ==<br />
<br />
'''Note''': All the following tasks are assuming you already have CKTester properly installed.<br> <br />
<br />
=== Running a specific ticket test<br> ===<br />
<br />
It's quite a frequent usecase when you're working on a particular ticket and quite straight forward that you can just point the browser to the location of that ticket test cell(e.g. [http://ckeditor.t/tt/4385/1.html http://ckeditor.t/tt/4385/1.html]), CKTester will redirect you to the fort as single cell criterial.<br />
<br />
== History ==<br />
<br />
CKTester is evolved from previous project '''FCKTest'''. <br />
<br />
<br></div>Garryyaohttps://docs-old.ckeditor.com/index.php?title=CKTester/Users_Guide&diff=2691CKTester/Users Guide2009-09-24T09:14:47Z<p>Garryyao: </p>
<hr />
<div>== Overview ==<br />
<br />
'''CKTester''' is our internal testing hub, created to provide seamless and integrated testing experience to our developers, been capable of managing and interfacing tests from various projects which may potentially rely on different testing frameworks/runners. Been designed with convenient authoring and ease of viewing the test cases in mind, it could be running independently in all situation from a browser&nbsp;: locally, on a web server or via secure connections. <br />
<br />
== How It Works ==<br />
<br />
=== Test Cell ===<br />
<br />
A '''test cell''' is the basic unit of a project's testing, a plain HTML file reside in individual project's testing sources, in which test suites/cases are written. It will be loaded and executed inside an iframe or popup window depends on the running of choice, so '''full page life cycle''' ( from page load to page destroy ) is guaranteed.<br><br />
<br />
Each cell has one key responsibility of '''reporting''' the sucess/failure/time of it's execution to the fort, this is done by cross-frame communication with parent/opener window. For this, the cell is required to include a bootstrap file: <br />
<pre>&lt;script type="text/javascript" src="{CKTester_ROOT}/bootstrap.js"&gt;&lt;/script&gt;<br />
</pre> <br />
The cell's entire testing environment, including testing target, runtime libraries, etc. will mostly be injected by the fort, which are declared by a meta tag of the HTML file. This inversion of control feature (IoC) make the cell testing framework neutral.<br><br />
<pre>// I'm a unit test for the editor(CKEditor) and the TCs within me are stable( been finalized ). <br />
&lt;meta name="tags" content="editor,unit,stable"&gt;<br />
</pre><br />
=== Profile ===<br />
<br />
A '''testing profile''' is a JavaScript configuration file which specify how a project is to be tested by CKTester. It contains a function which returns a configuration object including.&nbsp;<br> <br />
<br />
#'''Cells list'''&nbsp;: A list of key/values which tells where are the cells and what are the tags of each cell.<br>Key&nbsp;: The test cell '''file path''', where all the paths are relative to the runner; <br>Value&nbsp;: An array of '''tags''' of that cell.<br><br />
<br />
#'''Cell Resolvers&nbsp;''': An array of functions which were used to manipulate each cell's attributes, e.g. Inject necessary dependencies for cells which have certain tags. These are the complementary of the default resolvers that the '''fort '''already has.<br><br />
<br />
The file content will basically looks like: <br />
<pre>CKTester.profile = function ()<br />
{<br />
return<br />
{<br />
cells&nbsp;: [<br />
[ '/dt/unit/plugins/htmldataprocessor/1' ], // Implicit tag declaration( each sub path form a tag ).<br />
[ '/tt/1.html' , [ 'editor', 'unit', 'htmldataprocessor' ] ] // Explicit tag declaration.<br />
]<br />
cellResolvers&nbsp;:<br />
[<br />
function( cell )<br />
{<br />
var tags = cell.tags, env = cell.environment;<br />
<br />
// Inject CKEditor source.<br />
if( ( tags.indexOf( 'editor' )&nbsp;!= -1 )<br />
&amp;&amp; ( tags.indexOf( 'editor-ondemand' ) == -1 ) )<br />
env.push( '${CKEDITOR_ROOT}/ckeditor_source.js' );<br />
else if ( tags.indexOf( 'editor-ondemand' ) )<br />
env.push( '${CKEDITOR_ROOT}/ckeditor_basic_source.js' );<br />
<br />
// Inject CKEditor unit test library.<br />
if ( tags.indexOf( 'unit' )&nbsp;!= -1 )<br />
env.push( '${CKEDITOR_TEST_BRANCH_ROOT}/js/unit.js' );<br />
<br />
// Inject CKEditor manual test library.<br />
if ( tags.indexOf( 'manual' )&nbsp;!= -1 )<br />
env.push( '${CKEDITOR_TEST_BRANCH_ROOT}/js/manual.js' );<br />
}<br />
]<br />
};<br />
}<br />
</pre> <br />
'''Note''': the testing profile is recommanded to be generated automatically by the gen-profile tool script, though it could be altered manually.<br> <br />
<br />
=== Tags ===<br />
<br />
'''Tag''' is playing an important role as the '''annotation '''of a cell with the following aspects: <br />
<br />
#Environments( dependencies ) of a cell, e.g. if the cell has tags 'unit' and 'editor', it denote it must be running under a unit test runner( e.g. YUITest ), and the testing target is CKEditor; <br />
#Categories of the cell, useful to grouping similar cells. E.g. A cell with a path 'dt/core/dom/documentfragment' denote it's a design test for the core codes of dom module about document-fragment. <br />
#Any other reasonable denotation.<br />
<br />
=== Fort ===<br />
<br />
The '''Test Fort''' is a central hub for registering and running all the cells, which also consists of a UI to specifiy criterias and viewing report. <br />
<br />
The runner is driven by a specified profile( use the default one if not specified ), from which all cells are registering. Upon requesting by a specific testing criteria, it filtering down the registered cells to only execute the satisfied ones. <br />
<br />
During the loading of each cell before running, an extensible '''cell resolver''' will manipulate ( to figure out the required/requested resources of a specific cell ) the cell by analysing it's tags, guarantee the cell always has all the environment it should receive. These resources are typically composed of&nbsp;: <br />
<br />
*The testing target <br />
*The testing library <br />
*Any resources dedicated to the cell.<br><br />
<br />
At last the cell will be running in one of these '''two modes''' depend on the user: <br />
<br />
#Managed Mode&nbsp;: It's the default mode when it's running in a batch of cells by the forge, where the cell is running in an iframe. <br />
#Standalone Mode&nbsp;: When a cell is running separately, on the opposite of 'Managed Mode', the cell will be running inside a popup window, this is often used when it's a manual test case or detailed information about the TCs is required to be reviewed( e.g. which exactly test method failed in the TC? ).<br />
<br />
=== Testing Criteria ===<br />
<br />
A criteria is simply a URL request to the fort, tells which cells to be run. <br />
<br />
#It could contains a path to a '''profile''' to be used. <br />
#It could contains certain tags, so only with which the cells to be run. <br />
#It could explicitly specify a single cell location along with certain tags.<br />
<br />
Some example criteria look like: <br />
<br />
*Running all cells defined in a specified profile file: http://ckeditor.t/cktester/fort.html?profile=../myprofile.js <br />
*Running all the stable unit tests of the default profile: http://ckeditor.t/cktester/fort.html?cells=stable,unit <br />
*Running a specific ticket test with tags 'editor','unit','all'&nbsp;: http://ckeditor.t/cktester/fort.html?cells=http://ckeditor.t/tt/4397/1.html&amp;tags=editor,unit,all<br>( '''Note''': It's a shortcut to achieved the same criteria by just open the url of that individual cell (http://ckeditor.t/tt/4397/1.html) and it will be redirected correctly back to the forge. )<br><br />
<br />
== Installation ==<br />
<br />
'''Note''': Below we'll take the CKEditor project as an example to illustrate the install process. <br />
<br />
<br> First of all, checking out these three component: the staging project, it's test suites and CKTester eventually. <br />
<br />
#Checkout CKEditor's testing branch from [http://svn.fckeditor.net/CKEditor/tests SVN] ( We name the working copy path as CKEDITOR_TEST_ROOT below ). <br> <br />
#Checkout CKEditor trunk( or any other version are subjected to test ) from [http://svn.fckeditor.net/CKEditor/trunk/ SVN] into a folder ( e.g. ckeditor ) under CKEDITOR_TEST_ROOT ( We name the working copy path as CKEDITOR_ROOT below ).<br> <br />
#Checkout CKTester from [http://svn.fckeditor.net/CKTester SVN]&nbsp;into a folder( e.g. cktester ) under CKEDITOR_TEST_ROOT( We name the working copy path as CKTESTER_ROOT below ).<br />
<br />
Open the file {CKTESTER_ROOT}/variables.js.tpl with modification to the following variables:<br> <br />
<pre> // Absolute path point to the root path of CKEditor project.<br />
'CKEDITOR_ROOT'&nbsp;: '/ckeditor',<br />
<br />
// Point to the root path of CKEditor test branch.<br />
( You don't need to alter it if your web server's serving root from CKEDITOR_TEST_ROOT.<br />
'CKEDITOR_TEST_BRANCH_ROOT'&nbsp;: '/'<br />
</pre> <br />
At last, run the script {CKTESTER_ROOT}/_dev/gen-profile.bat(.sh) ( you'll need install [http://ant.apache.org/ Apache Ant] ) which helps you to generate the testing profile automatically by scanning the resources within {CKEDITOR_TEST_ROOT}. After that, you'll get a file created at {CKTESTER_ROOT}/template.js which looks basically like: <br />
<pre> CKTESTER.fort.getProfile = function ()<br />
{<br />
return {<br />
cells&nbsp;:<br />
[<br />
// Generated cell paths...<br />
],<br />
cellResolvers&nbsp;:<br />
[<br />
// Some Default cell resolvers. <br />
]<br />
};<br />
};<br />
<br />
</pre> <br />
It's done, now point your web browser at {CKEDITOR_TEST_ROOT}/index.html, a few pilot links there to kick start you testing.<br> <br />
<br />
<br> <br />
<br />
== Common Tasks ==<br />
<br />
'''Note''': All the following tasks are assuming you already have CKTester properly installed.<br> <br />
<br />
=== Running a specific ticket test<br> ===<br />
<br />
It's quite a frequent usecase when you're working on a particular ticket and quite straight forward that you can just point the browser to the location of that ticket test cell(e.g. [http://ckeditor.t/tt/4385/1.html http://ckeditor.t/tt/4385/1.html]), CKTester will redirect you to the fort as single cell criterial.<br />
<br />
== History ==<br />
<br />
CKTester is evolved from previous project '''FCKTest'''. <br />
<br />
<br></div>Garryyaohttps://docs-old.ckeditor.com/index.php?title=CKTester/Users_Guide&diff=2690CKTester/Users Guide2009-09-24T09:04:58Z<p>Garryyao: </p>
<hr />
<div>== Overview ==<br />
<br />
'''CKTester''' is our internal testing hub, created to provide seamless and integrated testing experience to our developers, been capable of managing and interfacing tests from various projects which may potentially rely on different testing frameworks/runners. Been designed with convenient authoring and ease of viewing the test cases in mind, it could be running independently in all situation from a browser&nbsp;: locally, on a web server or via secure connections. <br />
<br />
== How It Works ==<br />
<br />
=== Test Cell ===<br />
<br />
A '''test cell''' is the basic unit of a project's testing, a plain HTML file reside in individual project's testing sources, in which test suites/cases are written. It will be loaded and executed inside an iframe or popup window depends on the running of choice, so '''full page life cycle''' ( from page load to page destroy ) is guaranteed.<br><br />
<br />
Each cell has one key responsibility of '''reporting''' the sucess/failure/time of it's execution to the fort, this is done by cross-frame communication with parent/opener window. For this, the cell is required to include a bootstrap file: <br />
<pre>&lt;script type="text/javascript" src="{CKTester_ROOT}/bootstrap.js"&gt;&lt;/script&gt;<br />
</pre> <br />
The cell's entire testing environment, including testing target, runtime libraries, etc. will mostly be injected by the fort, which are declared by a meta tag of the HTML file. This inversion of control feature (IoC) make the cell testing framework neutral.<br><br />
<pre>// I'm a unit test for the editor(CKEditor) and the TCs within me are stable( been finalized ). <br />
&lt;meta name="tags" content="editor,unit,stable"&gt;<br />
</pre><br />
=== Profile ===<br />
<br />
A '''testing profile''' is a JavaScript configuration file which specify how a project is to be tested by CKTester. It contains a function which returns a configuration object including.&nbsp;<br> <br />
<br />
#'''Cells list'''&nbsp;: A list of key/values which tells where are the cells and what are the tags of each cell.<br>Key&nbsp;: The test cell '''file path''', where all the paths are relative to the runner; <br>Value&nbsp;: An array of '''tags''' of that cell.<br><br />
<br />
#'''Cell Resolvers&nbsp;''': An array of functions which were used to manipulate each cell's attributes, e.g. Inject necessary dependencies for cells which have certain tags. These are the complementary of the default resolvers that the '''fort '''already has.<br><br />
<br />
The file content will basically looks like: <br />
<pre>CKTester.profile = function ()<br />
{<br />
return<br />
{<br />
cells&nbsp;: [<br />
[ '/dt/unit/plugins/htmldataprocessor/1' ], // Implicit tag declaration( each sub path form a tag ).<br />
[ '/tt/1.html' , [ 'editor', 'unit', 'htmldataprocessor' ] ] // Explicit tag declaration.<br />
]<br />
cellResolvers&nbsp;:<br />
[<br />
function( cell )<br />
{<br />
var tags = cell.tags, env = cell.environment;<br />
<br />
// Inject CKEditor source.<br />
if( ( tags.indexOf( 'editor' )&nbsp;!= -1 )<br />
&amp;&amp; ( tags.indexOf( 'editor-ondemand' ) == -1 ) )<br />
env.push( '${CKEDITOR_ROOT}/ckeditor_source.js' );<br />
else if ( tags.indexOf( 'editor-ondemand' ) )<br />
env.push( '${CKEDITOR_ROOT}/ckeditor_basic_source.js' );<br />
<br />
// Inject CKEditor unit test library.<br />
if ( tags.indexOf( 'unit' )&nbsp;!= -1 )<br />
env.push( '${CKEDITOR_TEST_BRANCH_ROOT}/js/unit.js' );<br />
<br />
// Inject CKEditor manual test library.<br />
if ( tags.indexOf( 'manual' )&nbsp;!= -1 )<br />
env.push( '${CKEDITOR_TEST_BRANCH_ROOT}/js/manual.js' );<br />
}<br />
]<br />
};<br />
}<br />
</pre> <br />
'''Note''': the testing profile is recommanded to be generated automatically by the gen-profile tool script, though it could be altered manually.<br> <br />
<br />
=== Tags ===<br />
<br />
'''Tag''' is playing an important role as the '''annotation '''of a cell with the following aspects: <br />
<br />
#Environments( dependencies ) of a cell, e.g. if the cell has tags 'unit' and 'editor', it denote it must be running under a unit test runner( e.g. YUITest ), and the testing target is CKEditor; <br />
#Categories of the cell, useful to grouping similar cells. E.g. A cell with a path 'dt/core/dom/documentfragment' denote it's a design test for the core codes of dom module about document-fragment. <br />
#Any other reasonable denotation.<br />
<br />
=== Fort ===<br />
<br />
The '''Test Fort''' is a central hub for registering and running all the cells, which also consists of a UI to specifiy criterias and viewing report. <br />
<br />
The runner is driven by a specified profile( use the default one if not specified ), from which all cells are registering. Upon requesting by a specific testing criteria, it filtering down the registered cells to only execute the satisfied ones. <br />
<br />
During the loading of each cell before running, an extensible '''cell resolver''' will manipulate ( to figure out the required/requested resources of a specific cell ) the cell by analysing it's tags, guarantee the cell always has all the environment it should receive. These resources are typically composed of&nbsp;: <br />
<br />
*The testing target <br />
*The testing library <br />
*Any resources dedicated to the cell.<br><br />
<br />
At last the cell will be running in one of these '''two modes''' depend on the user: <br />
<br />
#Managed Mode&nbsp;: It's the default mode when it's running in a batch of cells by the forge, where the cell is running in an iframe. <br />
#Standalone Mode&nbsp;: When a cell is running separately, on the opposite of 'Managed Mode', the cell will be running inside a popup window, this is often used when it's a manual test case or detailed information about the TCs is required to be reviewed( e.g. which exactly test method failed in the TC? ).<br />
<br />
=== Testing Criteria ===<br />
<br />
A criteria is simply a URL request to the fort, tells which cells to be run. <br />
<br />
#It could contains a path to a '''profile''' to be used. <br />
#It could contains certain tags, so only with which the cells to be run. <br />
#It could explicitly specify a single cell location along with certain tags.<br />
<br />
Some example criteria look like: <br />
<br />
*Running all cells defined in a specified profile file: http://ckeditor.t/cktester/fort.html?profile=../myprofile.js <br />
*Running all the stable unit tests of the default profile: http://ckeditor.t/cktester/fort.html?cells=stable,unit <br />
*Running a specific ticket test with tags 'editor','unit','all'&nbsp;: http://ckeditor.t/cktester/fort.html?cells=http://ckeditor.t/tt/4397/1.html&amp;tags=editor,unit,all<br>( '''Note''': It's a shortcut to achieved the same criteria by just open the url of that individual cell (http://ckeditor.t/tt/4397/1.html) and it will be redirected correctly back to the forge. )<br><br />
<br />
== Installation ==<br />
<br />
'''Note''': Below we'll take the CKEditor project as an example to illustrate the install process. <br />
<br />
<br> First of all, checking out these three component: the staging project, it's test suites and CKTester eventually. <br />
<br />
#Checkout CKEditor's testing branch from [http://svn.fckeditor.net/CKEditor/tests SVN] ( We name the working copy path as CKEDITOR_TEST_ROOT below ). <br> <br />
#Checkout CKEditor trunk( or any other version are subjected to test ) from [http://svn.fckeditor.net/CKEditor/trunk/ SVN] into a folder ( e.g. ckeditor ) under CKEDITOR_TEST_ROOT ( We name the working copy path as CKEDITOR_ROOT below ).<br> <br />
#Checkout CKTester from [http://svn.fckeditor.net/CKTester SVN]&nbsp;into a folder( e.g. cktester ) under CKEDITOR_TEST_ROOT( We name the working copy path as CKTESTER_ROOT below ).<br />
<br />
Open the file {CKTESTER_ROOT}/variables.js.tpl with modification to the following variables:<br> <br />
<pre> // Absolute path point to the root path of CKEditor project.<br />
'CKEDITOR_ROOT'&nbsp;: '/ckeditor',<br />
<br />
// Point to the root path of CKEditor test branch.<br />
( You don't need to alter it if your web server's serving root from CKEDITOR_TEST_ROOT.<br />
'CKEDITOR_TEST_BRANCH_ROOT'&nbsp;: '/'<br />
</pre> <br />
At last, run the script {CKTESTER_ROOT}/_dev/gen-profile.bat(.sh) ( you'll need install [http://ant.apache.org/ Apache Ant] ) which helps you to generate the testing profile automatically by scanning the resources within {CKEDITOR_TEST_ROOT}. After that, you'll get a file created at {CKTESTER_ROOT}/template.js which looks basically like: <br />
<pre> CKTESTER.fort.getProfile = function ()<br />
{<br />
return {<br />
cells&nbsp;:<br />
[<br />
// Generated cell paths...<br />
],<br />
cellResolvers&nbsp;:<br />
[<br />
// Some Default cell resolvers. <br />
]<br />
};<br />
};<br />
<br />
</pre> <br />
It's done, now point your web browser at {CKEDITOR_TEST_ROOT}/index.html, a few pilot links there to kick start you testing.<br> <br />
<br />
<br> <br />
<br />
== Common Tasks ==<br />
<br />
== History ==<br />
<br />
CKTester is evolved from previous project '''FCKTest'''. <br />
<br />
<br></div>Garryyaohttps://docs-old.ckeditor.com/index.php?title=CKTester/Users_Guide&diff=2689CKTester/Users Guide2009-09-24T08:54:49Z<p>Garryyao: </p>
<hr />
<div>== Overview ==<br />
<br />
'''CKTester''' is our internal testing hub, created to provide seamless and integrated testing experience to our developers, been capable of managing and interfacing tests from various projects which may potentially rely on different testing frameworks/runners. Been designed with convenient authoring and ease of viewing the test cases in mind, it could be running independently in all situation from a browser&nbsp;: locally, on a web server or via secure connections. <br />
<br />
== How It Works ==<br />
<br />
=== Test Cell ===<br />
<br />
A '''test cell''' is the basic unit of a project's testing, a plain HTML file reside in individual project's testing source, in which test suites/cases are written. It will be loaded and executed inside an iframe or popup window depends on the running of choice, so '''full page life cycle''' ( from page load to page destroy ) is guaranteed. <br />
<br />
Each cell has one key responsibility of '''reporting''' the sucess/failure/time of it's execution to the fort, this is done by cross-frame communication with parent/opener window. For this, the cell is required to include a bootstrap file: <br />
<pre>&lt;script type="text/javascript" src="{CKTester_ROOT}/bootstrap.js"&gt;&lt;/script&gt;<br />
</pre> <br />
The cell's entire testing environment, including testing target, runtime libraries, etc. will mostly be injected by the fort, which are declared by a meta tag of the HTML file. <br />
<pre>// I'm a unit test for the editor(CKEditor) and the TCs within me are stable( been finalized ). <br />
&lt;meta name="tags" content="editor,unit,stable"&gt;<br />
</pre> <br />
A cell could be running in '''two modes''': <br />
<br />
#Managed Mode&nbsp;: It's the default mode when it's running in a batch of cells by the forge, where the cell is running in an iframe. <br />
#Standalone Mode&nbsp;: When a cell is running separately, on the opposite of 'Managed Mode', the cell will be running inside a popup window, this is<br />
<br />
often used when it's a manual test case or detailed information about the TCs is required to be reviewed( e.g. which exactly test method failed in the TC? ). <br />
<br />
<br> <br />
<br />
=== Profile ===<br />
<br />
A '''testing profile''' is a JavaScript configuration file which specify how a project is to be tested by CKTester. It contains a function which return a configuration object.&nbsp;<br> <br />
<br />
#Cells list&nbsp;: A list of key/values which tells where are the cells and what are the tags of each cell.<br>Key&nbsp;: The test cell '''file path''', where all the paths are relative to the runner; <br>Value&nbsp;: An array of '''tags''' of that cell.<br><br />
<br />
#Cell resolvers&nbsp;: An array of function which were used to manipulate each cell's attributes, e.g. Inject necessary dependencies for cells which have certain tags. These are the complementary of those resolvers that the '''fort '''already has.<br><br />
<br />
The file content will basically looks like: <br />
<pre>CKTester.profile = function ()<br />
{<br />
return<br />
{<br />
cells&nbsp;: [<br />
[ '/dt/unit/plugins/htmldataprocessor/1' ], // Implicit tag declaration( each sub path form a tag ).<br />
[ '/tt/1.html' , [ 'editor', 'unit', 'htmldataprocessor' ] ] // Explicit tag declaration.<br />
]<br />
cellResolvers&nbsp;:<br />
[<br />
function( cell )<br />
{<br />
var tags = cell.tags, env = cell.environment;<br />
<br />
// Inject CKEditor source.<br />
if( ( tags.indexOf( 'editor' )&nbsp;!= -1 )<br />
&amp;&amp; ( tags.indexOf( 'editor-ondemand' ) == -1 ) )<br />
env.push( '${CKEDITOR_ROOT}/ckeditor_source.js' );<br />
else if ( tags.indexOf( 'editor-ondemand' ) )<br />
env.push( '${CKEDITOR_ROOT}/ckeditor_basic_source.js' );<br />
<br />
// Inject CKEditor unit test library.<br />
if ( tags.indexOf( 'unit' )&nbsp;!= -1 )<br />
env.push( '${CKEDITOR_TEST_BRANCH_ROOT}/js/unit.js' );<br />
<br />
// Inject CKEditor manual test library.<br />
if ( tags.indexOf( 'manual' )&nbsp;!= -1 )<br />
env.push( '${CKEDITOR_TEST_BRANCH_ROOT}/js/manual.js' );<br />
}<br />
]<br />
};<br />
}<br />
</pre> <br />
'''Note''': the testing profile is recommanded to be generated automatically by the gen-profile tool script, but it could be altered manually as well.<br> <br />
<br />
=== Tags ===<br />
<br />
'''Tag''' is playing an important role as the indicator of a cell with the following aspects: <br />
<br />
#Environments( dependencies ) of a cell, e.g. if the cell has tags 'unit' and 'editor', it denote it must be running under a unit test runner( e.g. YUITest ), and the testing target is CKEditor; <br />
#Categories of the cell, could be used to grouping similar cells. E.g. A cell with a path 'dt/core/dom/documentfragment' denote it's design test for the core codes of dom module about document-fragment. <br />
#Any other reasonable denotation.<br />
<br />
=== Fort ===<br />
<br />
The '''Test Fort''' is a central hub for registering and running all the cells, which also consist of a UI to specific criteria and providing report. <br />
<br />
The runner is driven by the specified profile( use the default one if not specified ), from which all cells are registering. Upon requesting by a specific criteria, it filtering down the registered cells to only execute the satisfied ones. <br />
<br />
During the loading of each cell before running, an extensible '''cell resolver''' will manipulate ( to figure out the required/requested resources of a specific cell ) the cell by analysing it's tags, guarantee the cell always has all the environment it should receive. These resources are typically composed of&nbsp;: <br />
<br />
*The testing target <br />
*The testing library <br />
*Any resources dedicated to the cell.<br><br />
<br />
At last the cell will be running in one of these '''two modes''' depend on the user: <br />
<br />
#Managed Mode&nbsp;: It's the default mode when it's running in a batch of cells by the forge, where the cell is running in an iframe. <br />
#Standalone Mode&nbsp;: When a cell is running separately, on the opposite of 'Managed Mode', the cell will be running inside a popup window, this is<br />
<br />
often used when it's a manual test case or detailed information about the TCs is required to be reviewed( e.g. which exactly test method failed in the TC? ). <br />
<br />
=== Testing Criteria ===<br />
<br />
A criteria is simply a URL request to the fort which specify which cells to be run. <br />
<br />
#It could contains a path to the profile to be used. <br />
#It could contains certain tags only with which the cells to be run. <br />
#It could explicitly specify a single cell location along with certain tags.<br />
<br />
Some example criteria look like: <br />
<br />
*Running all cells defined in a specified profile file: http://ckeditor.t/cktester/fort.html?profile=../myprofile.js <br />
*Running all the stable unit tests of the default profile: http://ckeditor.t/cktester/fort.html?cells=stable,unit <br />
*Running a specific ticket test with tags 'editor','unit','all' : http://ckeditor.t/cktester/fort.html?cells=http://ckeditor.t/tt/4397/1.html&amp;tags=editor,unit,all<br>( '''Note''': It's a shortcut to achieved the same criteria by just open the url of that individual cell (http://ckeditor.t/tt/4397/1.html) and it will be redirected correctly back to the forge. )<br><br />
<br />
== Installation ==<br />
<br />
'''Note''': Below we'll take the CKEditor project as an example to illustrate the install process. <br />
<br />
<br> First of all, checking out these three component: the staging project, it's test suites and CKTester eventually. <br />
<br />
#Checkout CKEditor's testing branch from [http://svn.fckeditor.net/CKEditor/tests SVN] ( We name the working copy path as CKEDITOR_TEST_ROOT below ). <br> <br />
#Checkout CKEditor trunk( or any other version are subjected to test ) from [http://svn.fckeditor.net/CKEditor/trunk/ SVN] into a folder ( e.g. ckeditor ) under CKEDITOR_TEST_ROOT ( We name the working copy path as CKEDITOR_ROOT below ).<br> <br />
#Checkout CKTester from [http://svn.fckeditor.net/CKTester SVN]&nbsp;into a folder( e.g. cktester ) under CKEDITOR_TEST_ROOT( We name the working copy path as CKTESTER_ROOT below ).<br />
<br />
Open the file {CKTESTER_ROOT}/variables.js.tpl with modification to the following variables:<br> <br />
<pre> // Absolute path point to the root path of CKEditor project.<br />
'CKEDITOR_ROOT'&nbsp;: '/ckeditor',<br />
<br />
// Point to the root path of CKEditor test branch.<br />
( You don't need to alter it if your web server's serving root from CKEDITOR_TEST_ROOT.<br />
'CKEDITOR_TEST_BRANCH_ROOT'&nbsp;: '/'<br />
</pre> <br />
At last, run the script {CKTESTER_ROOT}/_dev/gen-profile.bat(.sh) ( you'll need install [http://ant.apache.org/ Apache Ant] ) which helps you to generate the testing profile automatically by scanning the resources within {CKEDITOR_TEST_ROOT}. After that, you'll get a file created at {CKTESTER_ROOT}/template.js which looks basically like: <br />
<pre> CKTESTER.fort.getProfile = function ()<br />
{<br />
return {<br />
cells&nbsp;:<br />
[<br />
// Generated cell paths...<br />
],<br />
cellResolvers&nbsp;:<br />
[<br />
// Some Default cell resolvers. <br />
]<br />
};<br />
};<br />
<br />
</pre> <br />
It's done, now point your web browser at {CKEDITOR_TEST_ROOT}/index.html, a few pilot links there to kick start you testing.<br> <br />
<br />
<br> <br />
<br />
== Common Tasks ==<br />
<br />
== History ==<br />
<br />
CKTester is evolved from previous project '''FCKTest'''. <br />
<br />
<br></div>Garryyaohttps://docs-old.ckeditor.com/index.php?title=CKTester/Users_Guide&diff=2688CKTester/Users Guide2009-09-24T08:25:17Z<p>Garryyao: </p>
<hr />
<div>== Overview ==<br />
<br />
'''CKTester''' is our internal testing hub, created to provide seamless and integrated testing experience to our developers, been capable of managing and interfacing tests from various projects which may potentially rely on different testing frameworks/runners. Been designed with convenient authoring and ease of viewing the test cases in mind, it could be running independently in all situation from a browser&nbsp;: locally, on a web server or via secure connections. <br />
<br />
== How It Works ==<br />
<br />
=== Test Cell ===<br />
<br />
A '''test cell''' is the basic unit of a project's testing, a plain HTML file reside in individual project's testing source, in which test suites/cases are written. It will be loaded and executed inside an iframe or popup window depends on the running of choice, so '''full page life cycle''' ( from page load to page destroy ) is guaranteed. <br />
<br />
Each cell has one key responsibility of '''reporting''' the sucess/failure/time of it's execution to the fort, this is done by cross-frame communication with parent/opener window. For this, the cell is required to include a bootstrap file: <br />
<pre>&lt;script type="text/javascript" src="{CKTester_ROOT}/bootstrap.js"&gt;&lt;/script&gt;<br />
</pre> <br />
The cell's entire testing environment, including testing target, runtime libraries, etc. will mostly be injected by the fort, which are declared by a meta tag of the HTML file. <br />
<pre>// I'm a unit test for the editor(CKEditor) and the TCs within me are stable( been finalized ). <br />
&lt;meta name="tags" content="editor,unit,stable"&gt;<br />
</pre> <br />
A cell could be running in '''two modes''': <br />
<br />
#Managed Mode&nbsp;: It's the default mode when it's running in a batch of cells by the forge, where the cell is running in an iframe. <br />
#Standalone Mode&nbsp;: When a cell is running separately, on the opposite of 'Managed Mode', the cell will be running inside a popup window, this is<br />
<br />
often used when it's a manual test case or detailed information about the TCs is required to be reviewed( e.g. which exactly test method failed in the TC? ). <br />
<br />
<br> <br />
<br />
=== Profile ===<br />
<br />
A '''testing profile''' is a JavaScript configuration file which specify how a project is to be tested by CKTester. It contains a function which return a configuration object.&nbsp;<br><br />
<br />
#Cells list&nbsp;: A list of key/values which tells where are the cells and what are the tags of each cell.<br>Key&nbsp;: The test cell '''file path''', where all the paths are relative to the runner; <br>Value&nbsp;: An array of '''tags''' of that cell.<br><br />
<br />
#Cell resolvers&nbsp;: An array of function which were used to manipulate each cell's attributes, e.g. Inject necessary dependencies for cells which have certain tags. These are the complementary of those resolvers that the '''fort '''already has.<br><br />
<br />
The file content will basically looks like: <br />
<pre>CKTester.profile = function ()<br />
{<br />
return<br />
{<br />
cells&nbsp;: [<br />
[ '/dt/unit/plugins/htmldataprocessor/1' ], // Implicit tag declaration( each sub path form a tag ).<br />
[ '/tt/1.html' , [ 'editor', 'unit', 'htmldataprocessor' ] ] // Explicit tag declaration.<br />
]<br />
cellResolvers&nbsp;:<br />
[<br />
function( cell )<br />
{<br />
var tags = cell.tags, env = cell.environment;<br />
<br />
// Inject CKEditor source.<br />
if( ( tags.indexOf( 'editor' )&nbsp;!= -1 )<br />
&amp;&amp; ( tags.indexOf( 'editor-ondemand' ) == -1 ) )<br />
env.push( '${CKEDITOR_ROOT}/ckeditor_source.js' );<br />
else if ( tags.indexOf( 'editor-ondemand' ) )<br />
env.push( '${CKEDITOR_ROOT}/ckeditor_basic_source.js' );<br />
<br />
// Inject CKEditor unit test library.<br />
if ( tags.indexOf( 'unit' )&nbsp;!= -1 )<br />
env.push( '${CKEDITOR_TEST_BRANCH_ROOT}/js/unit.js' );<br />
<br />
// Inject CKEditor manual test library.<br />
if ( tags.indexOf( 'manual' )&nbsp;!= -1 )<br />
env.push( '${CKEDITOR_TEST_BRANCH_ROOT}/js/manual.js' );<br />
}<br />
]<br />
};<br />
}<br />
</pre> <br />
'''Note''': the testing profile is recommanded to be generated automatically by the gen-profile tool script, but it could be altered manually as well.<br><br />
<br />
=== Tags ===<br />
<br />
'''Tag''' is playing an important role as the indicator of a cell with the following aspects: <br />
<br />
#Environments( dependencies ) of a cell, e.g. if the cell has tags 'unit' and 'editor', it denote it must be running under a unit test runner( e.g. YUITest ), and the testing target is CKEditor; <br />
#Categories of the cell, could be used to grouping similar cells. E.g. A cell with a path 'dt/core/dom/documentfragment' denote it's design test for the core codes of dom module about document-fragment. <br />
#Any other reasonable denotation.<br />
<br />
<br> <br />
<br />
== Installation ==<br />
<br />
'''Note''': Below we'll take the CKEditor project as an example to illustrate the install process. <br />
<br />
<br> First of all, checking out these three component: the staging project, it's test suites and CKTester eventually. <br />
<br />
#Checkout CKEditor's testing branch from [http://svn.fckeditor.net/CKEditor/tests SVN] ( We name the working copy path as CKEDITOR_TEST_ROOT below ). <br> <br />
#Checkout CKEditor trunk( or any other version are subjected to test ) from [http://svn.fckeditor.net/CKEditor/trunk/ SVN] into a folder ( e.g. ckeditor ) under CKEDITOR_TEST_ROOT ( We name the working copy path as CKEDITOR_ROOT below ).<br> <br />
#Checkout CKTester from [http://svn.fckeditor.net/CKTester SVN]&nbsp;into a folder( e.g. cktester ) under CKEDITOR_TEST_ROOT( We name the working copy path as CKTESTER_ROOT below ).<br />
<br />
Open the file {CKTESTER_ROOT}/variables.js.tpl with modification to the following variables:<br> <br />
<pre> // Absolute path point to the root path of CKEditor project.<br />
'CKEDITOR_ROOT'&nbsp;: '/ckeditor',<br />
<br />
// Point to the root path of CKEditor test branch.<br />
( You don't need to alter it if your web server's serving root from CKEDITOR_TEST_ROOT.<br />
'CKEDITOR_TEST_BRANCH_ROOT'&nbsp;: '/'<br />
</pre> <br />
At last, run the script {CKTESTER_ROOT}/_dev/gen-profile.bat(.sh) ( you'll need install [http://ant.apache.org/ Apache Ant] ) which helps you to generate the testing profile automatically by scanning the resources within {CKEDITOR_TEST_ROOT}. After that, you'll get a file created at {CKTESTER_ROOT}/template.js which looks basically like: <br />
<pre> CKTESTER.fort.getProfile = function ()<br />
{<br />
return {<br />
cells&nbsp;:<br />
[<br />
// Generated cell paths...<br />
],<br />
cellResolvers&nbsp;:<br />
[<br />
// Some Default cell resolvers. <br />
]<br />
};<br />
};<br />
<br />
</pre> <br />
It's done, now point your web browser at {CKEDITOR_TEST_ROOT}/index.html, a few pilot links there to kick start you testing.<br> <br />
<br />
<br> <br />
<br />
== Common Tasks ==<br />
<br />
== History ==<br />
<br />
CKTester is evolved from previous project '''FCKTest'''. <br />
<br />
<br></div>Garryyaohttps://docs-old.ckeditor.com/index.php?title=CKTester/Users_Guide&diff=2687CKTester/Users Guide2009-09-24T08:02:42Z<p>Garryyao: </p>
<hr />
<div>== Overview ==<br />
<br />
'''CKTester''' is our internal testing hub, created to provide seamless and integrated testing experience to our developers, been capable of managing and interfacing tests from various projects which may potentially rely on different testing frameworks/runners. Been designed with convenient authoring and ease of viewing the test cases in mind, it could be running independently in all situation from a browser&nbsp;: locally, on a web server or via secure connections. <br />
<br />
== How It Works ==<br />
<br />
=== Test Cell ===<br />
<br />
A '''test cell''' is the basic unit of a project's testing, a plain HTML file reside in individual project's testing source, in which test suites/cases<br />
are written. It will be loaded and executed inside an iframe or popup window depends on the running of choice, so '''full page life cycle'''<br />
( from page load to page destroy ) is guaranteed.<br />
<br />
Each cell has one key responsibility of '''reporting''' the sucess/failure/time of it's execution to the fort, this is<br />
done by cross-frame communication with parent/opener window. For this, the cell is required to include a bootstrap file:<br />
<pre><br />
<script type="text/javascript" src="{CKTester_ROOT}/bootstrap.js"></script><br />
</pre><br />
<br />
The cell's entire testing environment, including testing target, runtime libraries, etc. will mostly be injected by the fort,<br />
which are declared by a meta tag of the HTML file.<br />
<pre><br />
// I'm a unit test for the editor(CKEditor) and the TCs within me are stable( been finalized ). <br />
<meta name="tags" content="editor,unit,stable"><br />
</pre><br />
<br />
A cell could be running in '''two modes''':<br />
# Managed Mode : It's the default mode when it's running in a batch of cells by the forge, where the cell is running in an iframe.<br />
# Standalone Mode : When a cell is running separately, on the opposite of 'Managed Mode', the cell will be running inside a popup window, this is<br />
often used when it's a manual test case or detailed information about the TCs is required to be reviewed( e.g. which exactly test method failed in the TC? ).<br />
<br />
<br />
== Installation ==<br />
<br />
'''Note''': Below we'll take the CKEditor project as an example to illustrate the install process.<br />
<br />
<br />
First of all, checking out these three component: the staging project, it's test suites and CKTester eventually.<br />
#Checkout CKEditor's testing branch from [http://svn.fckeditor.net/CKEditor/tests SVN] ( We name the working copy path as CKEDITOR_TEST_ROOT below ). <br> <br />
#Checkout CKEditor trunk( or any other version are subjected to test ) from [http://svn.fckeditor.net/CKEditor/trunk/ SVN] into a folder ( e.g. ckeditor ) under CKEDITOR_TEST_ROOT ( We name the working copy path as CKEDITOR_ROOT below ).<br> <br />
#Checkout CKTester from [http://svn.fckeditor.net/CKTester SVN]&nbsp;into a folder( e.g. cktester ) under CKEDITOR_TEST_ROOT( We name the working copy path as CKTESTER_ROOT below ).<br />
<br />
Open the file {CKTESTER_ROOT}/variables.js.tpl with modification to the following variables:<br><br />
<pre> // Absolute path point to the root path of CKEditor project.<br />
'CKEDITOR_ROOT'&nbsp;: '/ckeditor',<br />
<br />
// Point to the root path of CKEditor test branch.<br />
( You don't need to alter it if your web server's serving root from CKEDITOR_TEST_ROOT.<br />
'CKEDITOR_TEST_BRANCH_ROOT'&nbsp;: '/'<br />
</pre><br />
<br />
At last, run the script {CKTESTER_ROOT}/_dev/gen-profile.bat(.sh) ( you'll need install [http://ant.apache.org/ Apache Ant] ) which helps you to generate the testing profile automatically by scanning the resources within {CKEDITOR_TEST_ROOT}. After that, you'll get a file created at {CKTESTER_ROOT}/template.js which looks basically like:<br />
<pre> CKTESTER.fort.getProfile = function ()<br />
{<br />
return {<br />
cells :<br />
[<br />
// Generated cell paths...<br />
],<br />
cellResolvers :<br />
[<br />
// Some Default cell resolvers. <br />
]<br />
};<br />
};<br />
<br />
</pre><br />
It's done, now point your web browser at {CKEDITOR_TEST_ROOT}/index.html, a few pilot links there to kick start you testing.<br><br />
<br />
<br><br />
<br />
== Common Tasks ==<br />
<br />
== History ==<br />
<br />
CKTester is evolved from previous project '''FCKTest'''. <br />
<br />
<br></div>Garryyaohttps://docs-old.ckeditor.com/index.php?title=CKTester/Users_Guide&diff=2686CKTester/Users Guide2009-09-24T07:43:48Z<p>Garryyao: /* Installation */</p>
<hr />
<div>== Overview ==<br />
<br />
'''CKTester''' is our internal testing hub, created to provide seamless and integrated testing experience to our developers, been capable of managing and interfacing tests from various projects which may potentially rely on different testing frameworks/runners. Been designed with convenient authoring and ease of viewing the test cases in mind, it could be running independently in all situation from a browser&nbsp;: locally, on a web server or via secure connections. <br />
<br />
== Installation ==<br />
<br />
'''Note''': Below we'll take the CKEditor project as an example to illustrate the install process.<br />
<br />
<br />
First of all, checking out these three component: the staging project, it's test suites and CKTester eventually.<br />
#Checkout CKEditor's testing branch from [http://svn.fckeditor.net/CKEditor/tests SVN] ( We name the working copy path as CKEDITOR_TEST_ROOT below ). <br> <br />
#Checkout CKEditor trunk( or any other version are subjected to test ) from [http://svn.fckeditor.net/CKEditor/trunk/ SVN] into a folder ( e.g. ckeditor ) under CKEDITOR_TEST_ROOT ( We name the working copy path as CKEDITOR_ROOT below ).<br> <br />
#Checkout CKTester from [http://svn.fckeditor.net/CKTester SVN]&nbsp;into a folder( e.g. cktester ) under CKEDITOR_TEST_ROOT( We name the working copy path as CKTESTER_ROOT below ).<br />
<br />
Open the file {CKTESTER_ROOT}/variables.js.tpl with modification to the following variables:<br><br />
<pre> // Absolute path point to the root path of CKEditor project.<br />
'CKEDITOR_ROOT'&nbsp;: '/ckeditor',<br />
<br />
// Point to the root path of CKEditor test branch.<br />
( You don't need to alter it if your web server's serving root from CKEDITOR_TEST_ROOT.<br />
'CKEDITOR_TEST_BRANCH_ROOT'&nbsp;: '/'<br />
</pre><br />
<br />
At last, run the script {CKTESTER_ROOT}/_dev/gen-profile.bat(.sh) ( you'll need install [http://ant.apache.org/ Apache Ant] ) which helps you to generate the testing profile automatically by scanning the resources within {CKEDITOR_TEST_ROOT}. After that, you'll get a file created at {CKTESTER_ROOT}/template.js which looks basically like:<br />
<pre> CKTESTER.fort.getProfile = function ()<br />
{<br />
return {<br />
cells :<br />
[<br />
// Generated cell paths...<br />
],<br />
cellResolvers :<br />
[<br />
// Some Default cell resolvers. <br />
]<br />
};<br />
};<br />
<br />
</pre><br />
It's done, now point your web browser at {CKEDITOR_TEST_ROOT}/index.html, a few pilot links there to kick start you testing.<br><br />
<br />
<br><br />
<br />
== Common Tasks ==<br />
<br />
== History ==<br />
<br />
CKTester is evolved from previous project '''FCKTest'''. <br />
<br />
<br></div>Garryyaohttps://docs-old.ckeditor.com/index.php?title=CKTester/Users_Guide&diff=2685CKTester/Users Guide2009-09-24T07:42:05Z<p>Garryyao: /* Installation */</p>
<hr />
<div>== Overview ==<br />
<br />
'''CKTester''' is our internal testing hub, created to provide seamless and integrated testing experience to our developers, been capable of managing and interfacing tests from various projects which may potentially rely on different testing frameworks/runners. Been designed with convenient authoring and ease of viewing the test cases in mind, it could be running independently in all situation from a browser&nbsp;: locally, on a web server or via secure connections. <br />
<br />
== Installation ==<br />
<br />
'''Note''': Below we'll take the CKEditor project as an example to illustrate the install process.<br />
<br />
<br />
First of all, checking out these three component: the staging project, it's test suites and CKTester eventually.<br />
#Checkout CKEditor's testing branch from SVN ( We name the working copy path as CKEDITOR_TEST_ROOT below ). <br> <br />
#Checkout CKEditor trunk( or any other version are subjected to test ) from [http://svn.fckeditor.net/CKEditor/trunk/ SVN] into a folder ( e.g. ckeditor ) under CKEDITOR_TEST_ROOT ( We name the working copy path as CKEDITOR_ROOT below ).<br> <br />
#Checkout CKTester from [http://svn.fckeditor.net/CKTester SVN]&nbsp;into a folder( e.g. cktester ) under CKEDITOR_TEST_ROOT( We name the working copy path as CKTESTER_ROOT below ).<br />
<br />
Open the file {CKTESTER_ROOT}/variables.js.tpl with modification to the following variables:<br><br />
<pre> // Absolute path point to the root path of CKEditor project.<br />
'CKEDITOR_ROOT'&nbsp;: '/ckeditor',<br />
<br />
// Point to the root path of CKEditor test branch.( You don't need to alter it if your web server's serving root from CKEDITOR_TEST_ROOT.<br />
'CKEDITOR_TEST_BRANCH_ROOT'&nbsp;: '/'<br />
</pre><br />
<br />
At last, run the script {CKTESTER_ROOT}/_dev/gen-profile.bat(.sh) ( you'll need install [http://ant.apache.org/ Apache Ant] ) which helps you to generate the testing profile automatically by scanning the resources within {CKEDITOR_TEST_ROOT}. After that, you'll get a file created at {CKTESTER_ROOT}/template.js which looks basically like:<br />
<pre> CKTESTER.fort.getProfile = function ()<br />
{<br />
return {<br />
cells :<br />
[<br />
// Generated cell paths...<br />
],<br />
cellResolvers :<br />
[<br />
// Some Default cell resolvers. <br />
]<br />
};<br />
};<br />
<br />
</pre><br />
It's done, now point your web browser at {CKEDITOR_TEST_ROOT}/index.html, a few pilot links there to kick start you testing.<br><br />
<br />
<br><br />
<br />
== Common Tasks ==<br />
<br />
== History ==<br />
<br />
CKTester is evolved from previous project '''FCKTest'''. <br />
<br />
<br></div>Garryyaohttps://docs-old.ckeditor.com/index.php?title=CKTester/Users_Guide&diff=2684CKTester/Users Guide2009-09-24T07:31:45Z<p>Garryyao: /* Installation */</p>
<hr />
<div>== Overview ==<br />
<br />
'''CKTester''' is our internal testing hub, created to provide seamless and integrated testing experience to our developers, been capable of managing and interfacing tests from various projects which may potentially rely on different testing frameworks/runners. Been designed with convenient authoring and ease of viewing the test cases in mind, it could be running independently in all situation from a browser&nbsp;: locally, on a web server or via secure connections. <br />
<br />
== Installation ==<br />
<br />
Below we'll take the CKEditor project as an example to illustrate the install process: <br />
<br />
#Checkout CKEditor's testing branch from SVN ( We name the working copy path as CKEDITOR_TEST_ROOT below ). <br> <br />
#Checkout CKEditor trunk( or any other version are subjected to test ) from [http://svn.fckeditor.net/CKEditor/trunk/ SVN] into a folder ( e.g. ckeditor ) under CKEDITOR_TEST_ROOT ( We name the working copy path as CKEDITOR_ROOT below ).<br> <br />
#Checkout CKTester from [http://svn.fckeditor.net/CKTester SVN]&nbsp;into a folder( e.g. cktester ) under CKEDITOR_TEST_ROOT( We name the working copy path as CKTESTER_ROOT below ). <br><br />
#Open the file {CKTESTER_ROOT}/variables.js.tpl with modification to the following variables:<br><br />
<pre> // Absolute path point to the root path of CKEditor project.<br />
'CKEDITOR_ROOT'&nbsp;: '/ckeditor',<br />
<br />
// Point to the root path of CKEditor test branch.( You don't need to alter it if your web server's serving root from CKEDITOR_TEST_ROOT.<br />
'CKEDITOR_TEST_BRANCH_ROOT'&nbsp;: '/'<br />
</pre><br />
#At last, run the script {CKTESTER_ROOT}/_dev/gen-profile.bat(.sh) ( you'll need install [http://ant.apache.org/ Apache Ant] ) which helps you to generate the testing profile automatically by scanning the resources within {CKEDITOR_TEST_ROOT}.<br><br>After that, you'll get a file created at {CKTESTER_ROOT}/template.js which looks basically like:<br />
<pre> CKTESTER.fort.getProfile = function ()<br />
{<br />
return {<br />
cells :<br />
[<br />
// Generated cell paths...<br />
],<br />
cellResolvers :<br />
[<br />
// Some Default cell resolvers. <br />
]<br />
};<br />
};<br />
<br />
</pre><br />
#It's done, now point your web browser at {CKEDITOR_TEST_ROOT}/index.html, a few pilot links there to kick start you testing.<br><br />
<br />
<br><br />
<br />
== Common Tasks ==<br />
<br />
== History ==<br />
<br />
CKTester is evolved from previous project '''FCKTest'''. <br />
<br />
<br></div>Garryyaohttps://docs-old.ckeditor.com/index.php?title=CKTester/Users_Guide&diff=2683CKTester/Users Guide2009-09-24T06:55:56Z<p>Garryyao: </p>
<hr />
<div>== Overview ==<br />
<br />
'''CKTester''' is our internal testing hub, created to provide seamless and integrated testing experience to our developers, been capable of managing and interfacing tests from various projects which may potentially rely on different testing frameworks/runners. Been designed with convenient authoring and ease of viewing the test cases in mind, it could be running independently in all situation from a browser&nbsp;: locally, on a web server or via secure connections. <br />
<br />
== Installation ==<br />
<br />
Below we'll take the CKEditor project as an example to illustrate the install process: <br />
<br />
#Checkout CKEditor trunk( or any other version are subjected to test) from [http://svn.fckeditor.net/CKEditor/trunk/ SVN]&nbsp;( We name the working copy path as CKEDITOR_ROOT below ).<br />
#Checkout CKEditor's testing branch from [http://svn.fckeditor.net/CKEditor/tests/ SVN]&nbsp;( We name the working copy path as CKEDITOR_TEST_ROOT below ).<br />
#Checkout CKTester from [http://svn.fckeditor.net/CKTester SVN]&nbsp;into a folder( e.g. cktester ) under CKEDITOR_TEST_ROOT( We name the working copy path as CKTESTER_ROOT below ).<br />
#Open the file {CKTESTER_ROOT}/variables.js.tpl with modification to the following variables:<br />
<pre><br />
</pre> <br />
#<br><br />
<br />
== Common Tasks ==<br />
<br />
== History ==<br />
<br />
CKTester is evolved from previous project '''FCKTest'''. <br />
<br />
<br></div>Garryyaohttps://docs-old.ckeditor.com/index.php?title=CKTester/Users_Guide&diff=2682CKTester/Users Guide2009-09-24T06:22:03Z<p>Garryyao: Initliaze CKTester user's guide</p>
<hr />
<div>== Overview ==<br />
'''CKTester''' is our internal testing hub, created to provide seamless and integrated testing experience to our developers, been capable of managing and interfacing tests from various projects which may potentially rely on different testing frameworks/runners. Been designed with convenient authoring and ease of viewing the test cases in mind, it could be running independently in all situation from a browser : locally, on a web server or via secure connections.<br />
<br />
== Installation ==<br />
<br />
== Common Tasks ==<br />
<br />
== History ==<br />
CKTester is evolved from previous project '''FCKTest'''.</div>Garryyao