Name |
Ceylon Test Platform Module |
---|---|
Description |
The Tests execute the code of the module under test and can make assertions about what it does. For example,
CONTENT
<a name="start"></a> GETTING STARTEDTests can be written as top level functions … test void shouldAlwaysSucceed() {} … or organized inside classes. class YodaTest() { test void shouldBeJedi() { assert(yoda is Jedi); } test void shouldHavePower() { assert(yoda.midichloriansCount > 1k); } } Notice the test annotation, which helps the framework to automatically discover tests. <a name="running"></a> RUNNINGThe most convenient way how to run tests is to use IDE integration
or via command line tools $ceylon test com.acme.mymodule Tests can be also run programmatically, via interface <a name="assertions"></a> ASSERTIONSAssertions can be evaluated by using the language's assert(is Hobbit frodo); assert(exists ring); assertNotEquals(frodo, sauron); assertThatException(() => gandalf.castLightnings()).hasType(`NotEnoughMagicPowerException`); A test function which completes without propagating an exception is
classified as a success. A test function which propagates
an <a name="callbacks"></a> LIFECYCLE CALLBACKSCommon initialization logic can be placed into separate functions, which run before or after each test. class StarshipTest() { beforeTest void init() => starship.chargePhasers(); afterTest void dispose() => starship.shutdownSystems(); Or it is possible to execute custom code, which will be executed only once before or after whole test run. Such callbacks can be only top level functions. beforeTestRun void createUniverse() { ... } afterTestRun void destroyUniverse() { ... } Other options how to hook into tests execution, is to implement <a name="disabling"></a> DISABLING TESTSSometimes you want to temporarily disable a test or a group of tests, this can be done via the ignore annotation. test ignore("still not implemented") void shouldBeFasterThanLight() { ... } Sometimes the conditions, if the test can be reliable executed,
are know only in runtime, in that case one of the test void shouldBeFasterThanLight() { assumeTrue(isWarpDriveAvailable); ... } <a name="tagging"></a> TAGGING TESTSTests or its containers can be tagged with one or more tags. Those tags can later be used to filter which tests will be executed. For example test, which is failing often, but from unknow reasons, can be marked as unstable … test tag("unstable") shared void shouldSucceedWithLittleLuck() { ... } … and then excluded from test execution $ceylon test --tag=!unstable com.acme.mymodule … or visa versa, we can execute only tests with this tag $ceylon test --tag=unstable com.acme.mymodule <a name="extension_points"></a> EXTENSION POINTSTest execution can be extended or completely changed by several extension points.
All extension points are child of marker interface
Extensions can be registered declaratively on several places: on concreate test, on class which contains tests, on whole package or even module, with help of testExtension annotation, for example: testExtension(`class DependencyInjectionInstancePostProcessor`, `class TransactionTestListener`) package com.acme; <a name="parameter_resolution"></a> PARAMETER RESOLUTIONIt is possible to write parameterized tests. The responsibility for resolving argument lists
is on Example: shared {[Integer, Integer]*} fibonnaciNumbers => {[1, 1], [2, 1], [3, 2], [4, 3], [5, 5], [6, 8] ...}; test parameters(`value fibonnaciNumbers`) shared void shouldCalculateFibonacciNumber(Integer input, Integer result) { assert(fibonacciNumber(input) == result); } |
Category |
SDK
The Ceylon SDK |
Rating | 5.00 (rated by 1 user) |
Last Published | Aug 21, 2017 |
Stats |
Downloads (JVM): 17730 Downloads (JS): 3379 Source downloads: 10654 |
Module links |
Home Code repository Issue tracker Imported By Browse |
1.3.3.1 | JVM JavaScript JVM: 1.2.x, 1.3.x (latest) JavaScript: Unknown (10/0) | Published Aug 21, 2017 |
Browse |
View docs |
|
1.3.3 | JVM JavaScript JVM: 1.2.x, 1.3.x (latest) JavaScript: Unknown (10/0) | Published Aug 21, 2017 |
Browse |
View docs |
|
1.3.2 | JVM JavaScript JVM: 1.2.x, 1.3.x (latest) JavaScript: Unknown (10/0) | Published Mar 1, 2017 |
Browse |
View docs |
|
1.3.1 | JVM JavaScript JVM: 1.2.x, 1.3.x (latest) JavaScript: 1.2.1, 1.2.2, 1.3.x (latest) | Published Nov 21, 2016 |
Browse |
View docs |
|
1.3.0 | JVM JavaScript JVM: 1.2.x, 1.3.x (latest) JavaScript: 1.2.1, 1.2.2, 1.3.x (latest) | Published Sep 15, 2016 |
Browse |
View docs |
|
1.2.2 | JVM JavaScript JVM: 1.2.x, 1.3.x (latest) JavaScript: 1.2.1, 1.2.2, 1.3.x (latest) | Published Mar 11, 2016 |
Browse |
View docs |
|
1.2.1-1 | JVM JavaScript JVM: 1.2.x, 1.3.x (latest) JavaScript: 1.2.1, 1.2.2, 1.3.x (latest) | Published Feb 15, 2016 |
Browse |
View docs |
|
1.2.1 | JVM JavaScript JVM: 1.2.x, 1.3.x (latest) JavaScript: 1.2.1, 1.2.2, 1.3.x (latest) | Published Feb 11, 2016 |
Browse |
View docs |
|
1.2.0 | JVM JavaScript JVM: 1.2.x, 1.3.x (latest) JavaScript: 1.2.0 (outdated) | Published Oct 28, 2015 |
Browse |
View docs |
|
1.1.0 | JVM JavaScript JVM: 1.1.0 (outdated) JavaScript: 1.1.0 (outdated) | Published Oct 8, 2014 |
Browse |
View docs |
|
1.0.0 | JVM JavaScript JVM: 1.0.0 (outdated) JavaScript: 1.0.0 (outdated) | Published Nov 11, 2013 |
Browse |
View docs |
|
0.6.1 | JVM JavaScript JVM: M6 (outdated) JavaScript: M6 (outdated) | Published Sep 24, 2013 |
Browse |
View docs |
|
0.6 | JVM JavaScript JVM: M6 (outdated) JavaScript: M6 (outdated) | Published Sep 20, 2013 |
Browse |
View docs |
|
0.5 | JVM JavaScript JVM: M5 (outdated) JavaScript: M5 (outdated) | Published Mar 14, 2013 |
Browse |
View docs |
+1 :-)