Name |
Ceylon test tool extension: asynchronous code testing |
---|---|
Description |
asyncTestis an extension to SDK
The extension is based on:
It is recommended to read documentation on The source code and examples are available at GitHub Content
<a name="procedure"></a> Test procedure
Notes> Both modules ceylon.test and herd.asynctest have to be imported to run testing. > Test executor blocks the thread until > Test functionsAny function or method marked with > If function (or upper-level container) is not marked with The test function arguments:
> If a number of test functions are declared within some class just a one instance of the class
is used for the overall test runcycle. This opens way to have some test interrelations. Please, remember
best-practices say the tests have to be independent. <a name="initialization"></a> Test initialization and disposing
> All Prepost functions may take arguments (excepting a top-level function marked with
If prepost function reports on failure (throwing exception or calling > All prepost functions are called disregard the failure reporting. Notes:
Test initialization and disposing exampleclass StarshipTest() { // called just a once before all tests ae executed shared beforeTestRun void createUniverse(AsyncPrePostContext context) { ... context.proceed(); } // called just a once after all tests are completed shared afterTestRun void destroyUniverse(AsyncPrePostContext context) { ... context.proceed(); } // called before each test function is executed shared beforeTest void init() => starship.chargePhasers(); // called after each test function is completed shared afterTest void dispose() => starship.shutdownSystems(); test async testPhasersAiming() { ... } test async testPhasersFire(AsynctestContext context) { ... context.complete(); } } <a name="initargs"></a> Prepost function arguments
[Integer] testUniverseSize = [1K]; arguments(`value testUniverseSize`) beforeTestRun void initializeStarshipTestSync(Integer universeSize) { ... } arguments(`value testUniverseSize`) beforeTestRun void initializeStarshipTestAsync(AsyncPrePostContext context, Integer universeSize) { ... } In the above example both functions > Test rulesTest rules provide more flexible way for test initialization / disposing and for modification the test behaviour.
See, details in > Order in which prepost functions are invoked is described in Test execution cycle section. <a name="instantiation"></a> Instantiation the test container classSometimes instantiation and initialization of the test container class requires
some complex logic or some asynchronous operations.
If the class declaration is marked with If no factory function is provided instantiation is done using metamodel staff calling class initializer with arguments
provided with > Just a one instance of the test class is used for the overall test runcycle it may cause several misalignments:
> From the other side having only one test class instance during overall test runcycle
helps to orginaze initialization logic in manner more suitable for asynchronous code testing. <a name="suites"></a> Test suites and concurrent executionTest functions are collected into suites, which are defined by:
So, each suite contains all top-level test functions in a given package
or all test methods of a given class. > This is implicit suite organization! All test and prepost functions within the given suite are always executed sequentially via a one
thread (note: any test function is free to run any number of threads it needs). By default the suites are executed sequentially also. In order to execute suites concurrently (each suite in separated thread)
the suite or upper-level container is to be marked with > Thread pool with fixed number of threads equals to number of available processors (cores)
is used to execute tests in concurrent mode. For example:
> Top-level prepost functions are not applicable to methods! <a name="cycle"></a> Test execution cycle
<a name="parameterized_section"></a> Value- and type- parameterized testingParameterized testing is performed using annotations to specify a generator of the test variants.
Basically, each test variant is a list of test function type parameters and arguments. <a name="runners"></a> Test runnersTest runners provide a way to control test function execution. <a name="matchers"></a> MatchersMatchers are intended to organize complex test conditions into a one flexible expression. Details of matching API are described in <a name="timeout_section"></a> Time out
Example, function timeout(1K) test async void doMyTest(...) {...} <a name="retry_section"></a> Retry testIf overall test runcycle (i.e. before callbacks - test function - test statements - after callbacks)
has to be retryed for each given test variant the <a name="conditions"></a> Conditional executionTest conditions can be specified via custom annotation which satisfies For an example, see > Conditions are evaluation up to the first unsatisfied condition.
So, there is no guarantee for a condition to be evaluated. <a name="benchmarking"></a> Benchmarking
<a name="charts"></a> Reporting test results using chartsChart is simply a set of plots, where each plot is a sequence of 2D points. |
Last Published | Sep 13, 2017 |
Stats |
Downloads (JVM): 1996 Downloads (JS): 0 Source downloads: 2716 |
Module links |
Home Code repository Issue tracker Imported By Browse |
0.7.1 | JVM JVM: 1.2.x, 1.3.x (latest) | Published Sep 13, 2017 |
Browse |
View docs |
|
0.7.0 | JVM JVM: 1.2.x, 1.3.x (latest) | Published Mar 27, 2017 |
Browse |
View docs |
|
0.6.0 | JVM JVM: 1.2.x, 1.3.x (latest) | Published Nov 28, 2016 |
Browse |
View docs |
|
0.5.2 | JVM JVM: 1.2.x, 1.3.x (latest) | Published Oct 18, 2016 |
Browse |
View docs |
|
0.5.1 | JVM JVM: 1.2.x, 1.3.x (latest) | Published Mar 12, 2016 |
Browse |
View docs |
|
0.5.0 | JVM JVM: 1.2.x, 1.3.x (latest) | Published Mar 9, 2016 |
Browse |
View docs |
|
0.4.0 | JVM JVM: 1.2.x, 1.3.x (latest) | Published Mar 5, 2016 |
Browse |
View docs |
|
0.3.0 | JVM JVM: 1.2.x, 1.3.x (latest) | Published Feb 29, 2016 |
Browse |
View docs |
|
0.2.0 | JVM JVM: 1.2.x, 1.3.x (latest) | Published Feb 25, 2016 |
Browse |
View docs |
|
0.1.0 | JVM JVM: 1.2.x, 1.3.x (latest) | Published Feb 19, 2016 |
Browse |
View docs |