
Parts of this document may be outdated. |
N4IDE contains built-in support for xpect based tests. The purpose of those is to create tests for N4IDE support for user code, not the user code itself. Users can create fileName.n4js.xt to write their test for a given N4IDE functionality. Those files can be executed (via context menu, run configurations, etc.) to verify user expectations.
When executing xpect tests, users can view the results in a special view available in the IDE: Window → Show View → Other → Test Views → Xpect View.
This view allows user to generate bug report (see Generating Bug Reports).
In case of failing tests, users can see additional information (e.g. a stacktrace), or call a comparison view.
Generating bug reports can be done when there is some .n4js.xt
file with all passing expectations, and at least one of them marked with FIXME. In this case icon of the executed test suite changes and via context menu user can call generate bug report option. When it is done, user can see contents of the bug generated in the console view. This output is prepared for out JIRA ticketing system.
There is also possibility to generate bug report via file selection and context menu. In this case xpect test is not executed, only bug contents are generated.
Xpect methods are special form of comments inside .xt files. General syntax for declaring usage of such method is XPECT marker followed by XpectMethodName and parameters for that method, all placed in comment. This can have three forms:
Single line comment (see the first comment in the listing below), Notice →
separating the method name and its parameters.
Multi line comment with one method invocation, notice -
separating the method name and its parameters
Multi line comment with multiple method invocations, simmilar to one above, but each line of method parameters indicates separate method invocation
//XPECT errors --> "Couldn't resolve reference to IdentifiableElement 'consoleX'." at "consoleX"
consoleX.log(10);
/*XPECT errors ---
"Couldn't resolve reference to IdentifiableElement 'logY'." at "logY"
---*/
console.logY(10);
/*XPECT errors ---
"Couldn't resolve reference to IdentifiableElement 'log'." at "log"
"Couldn't resolve reference to IdentifiableElement 'ref'." at "ref"
--- */
log(ref);
Errors, Warnings, Infos are xpect methods that allow to capture marker of given severity. Additionally Issues allows to allow markers of all above severities.
All of those methods can be used single invocations or as mutline invocations.
//XPECT errors --> "Couldn't resolve reference to IdentifiableElement 'x'." at "x"
console.log(x)
//XPECT warnings --> "Variable names should start with lower case letter." at "String"
var String = "some string"
No errors allows to catch (and suppress) marker of any severity (error, warning, info).
//XPECT noerrors --> "window object should be recognized"
console.log(window)
Output methods are special in sense that they are not intended to be used on single element of the script, but they apply to the whole script.
/* XPECT output ---
<==
stdout:
hello world
stderr:
==>
--- */
console.log("hello world")
Second method accepts regex expressions. This allows to deal with troublesome output (e.g. dates)
/* XPECT outputRegex ---
<==
stdout:
[^\n]*
stderr:
==>
--- */
console.log(new Date())
/* XPECT outputRegex ---
<==
stdout:
hello world
stderr:
[^\n]+
throw ' cruel world'
\^
cruel world
==>
--- */
console.log("hello world")
throw ' cruel world'
Xpect type methods allow test type inference, both for inferred type or expected type.
//XPECT type of 'probablySomeString' --> string
var probablySomeString = "some string";
var union{string,number} u;
// XPECT expectedType at 'null' --> {function(number?):string}
u.toString = null
There are also other methods provided, that allow to test quick fixes and content assist. Their parameters syntax is more complicated. Additionally they actively modify contents of the editor, or even close it if needed. Their usage exceeds scope of this document.