diff options
Diffstat (limited to 'docs/WriteYourTests')
16 files changed, 0 insertions, 818 deletions
diff --git a/docs/WriteYourTests/0_ProjectTree.md b/docs/WriteYourTests/0_ProjectTree.md deleted file mode 100644 index 1905d21..0000000 --- a/docs/WriteYourTests/0_ProjectTree.md +++ /dev/null @@ -1,172 +0,0 @@ -# Test architecture - -## Files tree and organization - -```tree - -"test" - +-- etc - | +-- aft-yourbinding.json - | +-- CMakeLists.txt - +-- fixture - | +-- a-script.sh - | +-- any-needed.data - | +-- CMakeLists.txt - | +-- data.json - +-- tests - | +-- CMakeLists.txt - | +-- test01.lua - | +-- test02.lua - | ... - -``` - -To integrate tests in your project, create a **test** subfolder at your project -root directory and fulfill it with appropriate files like shown as above. - -To make it simple you'll have to write your tests using lua language and store it -in the **tests** folder (as shown above) and create a JSON configuration file -*aft-yourbinding.json* to be able to launch your tests. You'll see in the next -section how to write a proper configuration file. - -> **Note** that if you create a new json file, its name has to start with "aft-" -> followed by the binder's name. (e.g. aft-low-can for the low-level-can-service) - -## Integration with CMake using App-templates - -To make the link between your test files, config files, data files -and the test binding, you will have to integrate them with CMake using the -App-templates. - -First you will have to create your CMake target using **PROJECT_TARGET_ADD** -with your target name as parameter, it will include the target to -your project. - -Then add your data files using **add_input_files** with your files in -parameter. - -Use **SET_TARGET_PROPERTIES** to fit the targets properties for macros -usage. Here you have to specify what type of your targets you want to include -in the widget package using the property **LABELS**. It will most likely either -be *TEST-DATA* or *TEST-CONFIG*. - -Here is the LABELS list: - -- **TEST-CONFIG**: JSON configuration files that will be used by the afb-test - binding to know how to execute tests. -- **TEST-DATA**: Resources used to test your binding. It is at least your test - plan and also could be fixtures and any files needed by your tests. These files - will appear in a separate test widget. -- **TEST-PLUGIN**: Shared library meant to be used as a binding - plugin. Binding would load it as a plugin to extend its functionalities. It - should be named with a special extension that you choose with SUFFIX cmake - target property or it'd be **.ctlso** by default. -- **TEST-HTDOCS**: Root directory of a web app. This target has to build its - directory and put its files in the ${CMAKE_CURRENT_BINARY_DIR}/${TARGET_NAME} -- **TEST-EXECUTABLE**: Entry point of your application executed by the AGL - Application Framework -- **TEST-LIBRARY**: An external 3rd party library bundled with the binding for its - own use in case the platform doesn't provide it. - -Here is a mapping between LABELS and directories where files will be placed in -the widget: - -- **EXECUTABLE** : \<wgtrootdir\>/bin -- **BINDING-CONFIG** : \<wgtrootdir\>/etc -- **BINDING** | **BINDINGV2** | **BINDINGV3** | **LIBRARY** : \<wgtrootdir\>/lib -- **PLUGIN** : \<wgtrootdir\>/lib/plugins -- **HTDOCS** : \<wgtrootdir\>/htdocs -- **BINDING-DATA** : \<wgtrootdir\>/var -- **DATA** : \<wgtrootdir\>/var - -And about test dedicated **LABELS**: - -- **TEST-EXECUTABLE** : \<TESTwgtrootdir\>/bin -- **TEST-CONFIG** : \<TESTwgtrootdir\>/etc -- **TEST-PLUGIN** : \<TESTwgtrootdir\>/lib/plugins -- **TEST-HTDOCS** : \<TESTwgtrootdir\>/htdocs -- **TEST-DATA** : \<TESTwgtrootdir\>/var - -> **TIP** you should use the prefix _afb-_ with your **BINDING* targets which -> stand for **Application Framework Binding**. - -You will find in further description about it [here](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/sdk-devkit/docs/part-2/2_4-Use-app-templates.html#targets-properties). - -Here is an example of a proper CMake file to include your LUA test files: - -```CMake -PROJECT_TARGET_ADD(test-files) - - file(GLOB LUA_FILES "*.lua") - add_input_files("${LUA_FILES}") - - SET_TARGET_PROPERTIES(${TARGET_NAME} PROPERTIES - LABELS "TEST-DATA" - OUTPUT_NAME ${TARGET_NAME} - ) -``` - -## Build the test widget - -### Using CMake Apps module or app-templates - -> **Note** the CMake module is the new way to use **app-templates** - -To launch tests on a target board, you need to build a test widget. Using the -SDK, you only have to set the variable *BUILD_TEST_WGT=TRUE* when configuring -the project. - -Example from another project than **afb-test**: - -```bash -mkdir build -cd build -cmake -DBUILD_TEST_WGT=TRUE .. -make -make widget -``` - -### Without using CMake Apps module or app-templates - -Like you'd build a regular widget create a directory where you'll put your tests -materials: LUA tests, configuration and fixture files. - -Then create in that directory a **bin** directory where you'll put this -[script](https://gerrit.automotivelinux.org/gerrit/gitweb?p=apps/app-templates.git;a=blob_plain;f=test-widget/launcher.sh.in;h=005c43357db3daa71b66d95d2486cd13f5cee482;hb=refs/heads/master) and name it **launcher**. To finish, you'll also need a -widget configuration file. You can use the example provided [here](https://gerrit.automotivelinux.org/gerrit/gitweb?p=apps/app-templates.git;a=blob_plain;f=test-widget/test-config.xml.in;hb=refs/heads/master) and edit it -to fit your needs by replacing the variables surrounded by **@** characters. - -Example from another project than **afb-test**: - -```bash -cd build -BUILDDIR="$(pwd)" -mkdir -p package-test/bin -cd package-test -wget https://gerrit.automotivelinux.org/gerrit/gitweb?p=apps/app-templates.git;a=blob_plain;f=test-widget/launcher.sh.in;h=005c43357db3daa71b66d95d2486cd13f5cee482;hb=refs/heads/master -O bin/launcher -wget https://gerrit.automotivelinux.org/gerrit/gitweb?p=apps/app-templates.git;a=blob_plain;f=test-widget/test-config.xml.in;hb=refs/heads/master -O config.xml -vim config.xml -``` - -Then once your widget content directory is complete, use **wgtpkg-pack** utility -to create the test widget. - -```bash -cd ${BUILDDIR} -wgtpkg-pack -f -o <project_name>-test.wgt package-test -``` - -## Run the test widget on the target - -Once built you can send the wgt file to your target board and launch the tests -using **afm-test** as follow: - -```bash -afm-test <path-to-your-test.wgt> -``` - -**afm-test** installs the test wgt file, then runs it and uninstalls it. - -> **CAUTION**: Be cautious to not specify a regular widget's app, else it will -> be uninstalled at the end of the operation. So, if it was an important -> service/binding, others bindings or apps relying on it won't work. diff --git a/docs/WriteYourTests/1_BindingConfiguration.md b/docs/WriteYourTests/1_BindingConfiguration.md deleted file mode 100644 index 2bd31c5..0000000 --- a/docs/WriteYourTests/1_BindingConfiguration.md +++ /dev/null @@ -1,112 +0,0 @@ -# Test configuration - -The file `aft-test.json` contains the controller binding configuration. Here, -you have to change or define the *files* key in the *args* object of the -*testVerb* section, *testVerb* is an array of verb definition which are -meant to launch different LUA test files. - -Also you MUST specify which *api* you need to trace to perform your tests. -Specify which api to trace using a pattern. - -Edit the JSON array to point to your tests files. - -Here is an example: - -```json -{ - "id": "http://iot.bzh/download/public/schema/json/ctl-schema.json#", - "$schema": "http://iot.bzh/download/public/schema/json/ctl-schema.json#", - "metadata": { - "uid": "Test", - "version": "1.0", - "api": "afTest", - "info": "Binding made to test other bindings", - "require": [ - "hello" - ] - }, - "testVerb": { - "uid": "launch_all_tests", - "info": "Launch all the tests", - "action": "lua://AFT#_launch_test", - "args": { - "trace": "hello", - "files": ["aftTest.lua","helloworld.lua"] - } - } -} -``` - -and another example which tests the low-can api: - -```json -{ - "id": "http://iot.bzh/download/public/schema/json/ctl-schema.json#", - "$schema": "http://iot.bzh/download/public/schema/json/ctl-schema.json#", - "metadata": { - "uid": "Test", - "version": "1.0", - "api": "aft-aftest", - "info": "Binding made to test other bindings", - "require": [ - "low-can" - ] - }, - "testVerb": { - "uid": "launch_all_tests", - "info": "Launch all the tests", - "action": "lua://AFT#_launch_test", - "args": { - "trace": "low-can", - "files": [ "aftTest.lua", "mapis-tests.lua" ] - } - }, - "mapis": [{ - "uid": "low-can", - "info": "Faked low-can API", - "libs": "mapi_low-can.lua", - "verbs": [ - { - "uid": "subscribe", - "info": "Subscribe to CAN signals events", - "action": "lua://low-can#_subscribe" - }, - { - "uid": "unsubscribe", - "info": "Unsubscribe previously suscribed signals.", - "action": "lua://low-can#_unsubscribe" - }, - { - "uid": "get", - "info": "get a current value of CAN message", - "action": "lua://low-can#_get" - }, - { - "uid": "list", - "info": "get a supported CAN message list", - "action": "lua://low-can#_list" - }, - { - "uid": "auth", - "info": "Authenticate session to be raise Level Of Assurance.", - "action": "lua://low-can#_auth" - }, - { - "uid": "write", - "info": "Write a CAN messages to the CAN bus.", - "action": "lua://low-can#_write" - } - ], - "events": [{ - "uid": "low-can/diagnostic_messages", - "action": "lua://AFT#_evt_catcher_" - },{ - "uid": "low-can/messages_engine_speed", - "action": "lua://AFT#_evt_catcher_" - },{ - "uid": "low-can/messages_vehicle_speed", - "action": "lua://AFT#_evt_catcher_" - }] - }] -} -``` diff --git a/docs/WriteYourTests/2_LUATestFiles.md b/docs/WriteYourTests/2_LUATestFiles.md deleted file mode 100644 index 05752dd..0000000 --- a/docs/WriteYourTests/2_LUATestFiles.md +++ /dev/null @@ -1,15 +0,0 @@ -# LUA Test files - -You have two differents things to take in account when you'll write your tests -using this framework: *test* and *assertions*. - -*Assertions* are functions meant to test an atomic operation result. -(ie: `1+1 = 2` is an assertion) - -*Test* functions represent a test (Unbelievable), they represent a set of one or -several *assertions* which are all needed to succeed to valid the test. - -The framework came with several *test* and *assertion* functions to simply be -able to test verb calls and events receiving. Use the simple one as often as -possible and if you need more use the one that calls a callback. Specifying a -callback let you add assertions and enrich the test. diff --git a/docs/WriteYourTests/Introduction.md b/docs/WriteYourTests/Introduction.md deleted file mode 100644 index a8b457b..0000000 --- a/docs/WriteYourTests/Introduction.md +++ /dev/null @@ -1,10 +0,0 @@ -# Write your test - -Follow this section to know how to write your test. - -Section's Table of content : - -* [Project Tree](0_ProjectTree.html) -* [Binding configuration](1_BindingConfiguration.html) -* [LUA test files](2_LUATestFiles.html) -* [References](Reference/Introduction.html) diff --git a/docs/WriteYourTests/Reference/0_BindingTestFunctions.md b/docs/WriteYourTests/Reference/0_BindingTestFunctions.md deleted file mode 100644 index 8da86da..0000000 --- a/docs/WriteYourTests/Reference/0_BindingTestFunctions.md +++ /dev/null @@ -1,100 +0,0 @@ -# Binding Test functions - -* **_AFT.testVerbStatusSuccess(testName, api, verb, args, setUp, tearDown)** - - Simply test that the call of a verb successfully returns. - - *setUp* and *tearDown* are functions that can be added to your context, - it works just like **_AFT.beforeEach()** and **_AFT.afterEach()**, - *setUp* will be ran before your *testFunction* and **_AFT.beforeEach()** - (if set) functions, *tearDown* will be ran after your *testFunction* and - **_AFT.afterEach()** (if set) functions. - -* **_AFT.testVerbStatusError(testName, api, verb, args, setUp, tearDown)** - - The inverse than above. - - *setUp* and *tearDown* are functions that can be added to your context, - it works just like **_AFT.beforeEach()** and **_AFT.afterEach()**, - *setUp* will be ran before your *testFunction* and **_AFT.beforeEach()** - (if set) functions, *tearDown* will be ran after your *testFunction* and - **_AFT.afterEach()** (if set) functions. - -* **_AFT.testVerbResponseEquals(testName, api, verb, args, expectedResponse, setUp, tearDown)** - - Test that the call of a verb successfully returns and that verb's response - is equals to the *expectedResponse*. - - *setUp* and *tearDown* are functions that can be added to your context, - it works just like **_AFT.beforeEach()** and **_AFT.afterEach()**, *setUp* - will be ran before your *testFunction* and **_AFT.beforeEach()** (if set) - functions, *tearDown* will be ran after your *testFunction* and - **_AFT.afterEach()** (if set) functions. - -* **_AFT.testVerbResponseEqualsError(testName, api, verb, args, expectedResponse, setUp, tearDown)** - - The inverse than above. - - *setUp* and *tearDown* are functions that can be added to your context, it works - just like **_AFT.beforeEach()** and **_AFT.afterEach()**, *setUp* will be ran - before your *testFunction* and **_AFT.beforeEach()** (if set) functions, - *tearDown* will be ran after your *testFunction* and **_AFT.afterEach()** (if - set) functions. - -* **_AFT.testVerbCb(testName, api, verb, args, expectedResponse, callback, setUp, tearDown)** - - Test the call of a verb with a custom callback. From this callback you - will need to make some assertions on what you need (verb JSON return object - content mainly). - - If you don't need to test the response simply specify an empty LUA table. - - *setUp* and *tearDown* are functions that can be added to your context, it works - just like **_AFT.beforeEach()** and **_AFT.afterEach()**, *setUp* will be ran - before your *testFunction* and **_AFT.beforeEach()** (if set) functions, - *tearDown* will be ran after your *testFunction* and **_AFT.afterEach()** (if - set) functions. - -* **_AFT.testVerbCbError(testName, api, verb, args, expectedResponse, callback, setUp, tearDown)** - - Should return success on failure. - - *setUp* and *tearDown* are functions that can be added to your context, it works - just like **_AFT.beforeEach()** and **_AFT.afterEach()**, *setUp* will be ran - before your *testFunction* and **_AFT.beforeEach()** (if set) functions, - *tearDown* will be ran after your *testFunction* and **_AFT.afterEach()** (if - set) functions. - -* **_AFT.testEvtReceived(testName, eventName, timeout, setUp, tearDown)** - - Prior to be able to check that an event has been received, you have to - register the event with the test framework using **_AFT.addEventToMonitor** - function. - - Check if an event has been correctly received in time (timeout in µs). An event - name use the application framework naming scheme: **api/event_name**. - -* **_AFT.testEvtNotReceived(testName, eventName, timeout, setUp, tearDown)** - - Prior to be able to check that an event has not been received, you have to - register the event with the test framework using **_AFT.addEventToMonitor** - function. - - Check if an event has not been correctly received in time (timeout in µs). An - event name use the application framework naming scheme: **api/event_name**. - -* **_AFT.testGrpEvtReceived(testName, eventGrp, timeout, setUp, tearDown)** - - Prior to be able to check that a group of event (a table of event) has been - received, you have to register the event with the test framework using - **_AFT.addEventToMonitor** function. - - The table has to have this format: - ```lua - eventGrp = {["api/event_name_1"]=1,["api/event_name_2"]=2,["api/event_name_3"]=5} - ``` - As you can see, in the table, event names are table keys and the value stored are - the number of time that the events have to be received. - - Check if events has been correctly received in time (timeout in µs). An - event name use the application framework naming scheme: **api/event_name**.
\ No newline at end of file diff --git a/docs/WriteYourTests/Reference/1_BindingAssertFunctions.md b/docs/WriteYourTests/Reference/1_BindingAssertFunctions.md deleted file mode 100644 index 918bd04..0000000 --- a/docs/WriteYourTests/Reference/1_BindingAssertFunctions.md +++ /dev/null @@ -1,64 +0,0 @@ -# Binding Assert functions - -* **_AFT.assertVerbStatusSuccess(api, verb, args)** - - Simply test that the call of a verb successfully returns. - -* **_AFT.assertVerbStatusError(api, verb, args)** - - The inverse than above. - -* **_AFT.assertVerbResponseEquals(api, verb, args, expectedResponse)** - - Test that the call of a verb successfully returns and that verb's response - is equals to the *expectedResponse*. - -* **_AFT.assertVerbResponseEqualsError(api, verb, args, expectedResponse)** - - The inverse than above. - -* **_AFT.assertVerbCb(api, verb, args, expectedResponse, callback)** - - Test the call of a verb with a custom callback. From this callback you - will need to make some assertions on what you need (verb JSON return object - content mainly). - - If you don't need to test the response simply specify an empty LUA table. - -* **_AFT.assertVerbCbError(api, verb, args, expectedResponse, callback)** - - Should return success on failure. - -* **_AFT.assertEvtReceived(eventName, timeout)** - - Prior to be able to check that an event has been received, you have to - register the event with the test framework using **_AFT.addEventToMonitor** - function. - - Check if an event has been correctly received in time (timeout in µs). - An event name use the application framework naming scheme: **api/event_name**. - -* **_AFT.assertEvtNotReceived(eventName, timeout)** - - Prior to be able to check that an event has been received, you have to - register the event with the test framework using **_AFT.addEventToMonitor** - function. - - Check if an event has been correctly received in time (timeout in µs). - An event name use the application framework naming scheme: **api/event_name**. - -* **_AFT.assertGrpEvtReceived(eventGrp, timeout)** - - Prior to be able to check that a group of event (a table of event) has been - received, you have to register the event with the test framework using - **_AFT.addEventToMonitor** function. - - The table has to have this format: - ```lua - eventGrp = {["api/event_name_1"]=1,["api/event_name_2"]=2,["api/event_name_3"]=5} - ``` - As you can see, in the table, event names are table keys and the value stored are - the number of time that the events have to be received. - - Check if events has been correctly received in time (timeout in µs). - An event name use the application framework naming scheme: **api/event_name**.
\ No newline at end of file diff --git a/docs/WriteYourTests/Reference/2_TestFrameworkFunctions.md b/docs/WriteYourTests/Reference/2_TestFrameworkFunctions.md deleted file mode 100644 index 20184ec..0000000 --- a/docs/WriteYourTests/Reference/2_TestFrameworkFunctions.md +++ /dev/null @@ -1,59 +0,0 @@ -# Test Framework functions - -* **_AFT.addEventToMonitor(eventName, callback)** - - Add a binding event in the test framework to be able to assert its reception - . You'll need to add as much as events you expect to receive. You could also - specify a callback to test deeper that the event is as you want to. The - callback will happens after the assertion that it has been received so you - can work on data that the event eventually carry. - -* **_AFT.setJunitFile(filePath)** - - Set the *JUnit* file path. When *JUnit* is set as the output type for the - test framework. - -* **_AFT.setBeforeEach(function)** - - Set the **_AFT.beforeEach()** function which is used to run the *function* - before each tests. - -* **_AFT.setAfterEach(function)** - - Set the **_AFT.afterEach()** function which is used to run the *function* - after each tests. - -* **_AFT.setBeforeAll(function)** - - Set the **_AFT.beforeAll()** function which is used to run the *function* - before all tests. If the given function is successful it has to return 0 - else it will return an error. - -* **_AFT.setAfterAll(function)** - - Set the **_AFT.afterAll()** function which is used to run the *function* - after all tests. If the given function is successful it has to return 0 - else it will return an error. - -* **_AFT.describe(testName, testFunction, setUp, tearDown)** - - Give a context to a custom test. *testFunction* will be given the name - provided by *testName* and will be tested. - - *setUp* and *tearDown* are functions that can be added to your context, - it works just like **_AFT.beforeEach()** and **_AFT.afterEach()**, - *setUp* will be ran before your *testFunction* and **_AFT.beforeEach()** - (if set) functions, *tearDown* will be ran after your *testFunction* and - **_AFT.afterEach()** (if set) functions. - -* **_AFT.setBefore(testName, beforeTestFunction)** - Set a function to be ran at the beginning of the given *testName* function. - - ```lua - _AFT.testVerbStatusSuccess('testPingSuccess','hello', 'ping', {}) - _AFT.setBefore("testPingSuccess",function() print("~~~~~ Begin testPingSuccess ~~~~~") end) - _AFT.setAfter("testPingSuccess",function() print("~~~~~ End testPingSuccess ~~~~~") end) - ``` - -* **_AFT.setBefore(testName, beforeTestFunction)** - Set a function to be ran at the end of the given *testName* function.
\ No newline at end of file diff --git a/docs/WriteYourTests/Reference/Introduction.md b/docs/WriteYourTests/Reference/Introduction.md deleted file mode 100644 index 8de5a15..0000000 --- a/docs/WriteYourTests/Reference/Introduction.md +++ /dev/null @@ -1,10 +0,0 @@ -# References - -Follow this section to know which functions are available !! - -Section's Table of content : - -* [Binding test functions](0_BindingTestFunctions.html) -* [Binding assert functions](1_BindingAssertFunctions.html) -* [Test framework functions](2_TestFrameworkFunctions.html) -* [LUAUnit assertion functions](LuaUnitAssertionFunctions/Introduction.html)
\ No newline at end of file diff --git a/docs/WriteYourTests/Reference/LuaUnitAssertionFunctions/0_GeneralAssertions.md b/docs/WriteYourTests/Reference/LuaUnitAssertionFunctions/0_GeneralAssertions.md deleted file mode 100644 index 4a719b6..0000000 --- a/docs/WriteYourTests/Reference/LuaUnitAssertionFunctions/0_GeneralAssertions.md +++ /dev/null @@ -1,32 +0,0 @@ -# General Assertions - -* **_AFT.assertEquals(actual, expected)** - - Assert that two values are equal. - - For tables, the comparison is a deep comparison : - - * number of elements must be the same - * tables must contain the same keys - * each key must contain the same values. The values are also compared recursively with deep comparison. - - LuaUnit provides other table-related assertions, see [Table assertions](http://luaunit.readthedocs.io/en/luaunit_v3_2_1/#assert-table) - -* **_AFT.assertNotEquals(actual, expected)** - - Assert that two values are different. The assertion fails if the two values are identical. - - It also uses table deep comparison. - -* **_AFT.assertAlmostEquals(actual, expected, margin)** - - Assert that two floating point numbers are almost equal. - - When comparing floating point numbers, strict equality does not work. - Computer arithmetic is so that an operation that mathematically yields - 1.00000000 might yield 0.999999999999 in lua . That’s why you need an - almost equals comparison, where you specify the error margin. - -* **_AFT.assertNotAlmostEquals(actual, expected, margin)** - - Assert that two floating point numbers are not almost equal.
\ No newline at end of file diff --git a/docs/WriteYourTests/Reference/LuaUnitAssertionFunctions/1_ValueAssertions.md b/docs/WriteYourTests/Reference/LuaUnitAssertionFunctions/1_ValueAssertions.md deleted file mode 100644 index ed927cd..0000000 --- a/docs/WriteYourTests/Reference/LuaUnitAssertionFunctions/1_ValueAssertions.md +++ /dev/null @@ -1,58 +0,0 @@ -# Value assertions - -* **_AFT.assertEvalToTrue(value)** - - Assert that a given value evals to true. Lua coercion rules are applied so - that values like 0,"",1.17 succeed in this assertion. If provided, extra_msg - is a string which will be printed along with the failure message. - -* **_AFT.assertEvalToFalse(Value)** - - Assert that a given value eval to *false*. Lua coercion rules are applied so - that *nil* and *false* succeed in this assertion. If provided, extra_msg is a - string which will be printed along with the failure message. - -* **_AFT.assertIsTrue(value)** - - Assert that a given value compares to true. Lua coercion rules are applied so - that values like 0, "", 1.17 all compare to true. - -* **_AFT.assertIsFalse(value)** - - Assert that a given value compares to false. Lua coercion rules are applied so - that only nil and false all compare to false. - -* **_AFT.assertIsNil(value)** - - Assert that a given value is nil . - -* **_AFT.assertNotIsNil(value)** - - Assert that a given value is not *nil* . Lua coercion rules are applied - so that values like ``0``, ``""``, ``false`` all validate the assertion. - If provided, *extra_msg* is a string which will be printed along with the - failure message. - -* **_AFT.assertIs(actual, expected)** - - Assert that two variables are identical. For string, numbers, boolean and - for nil, this gives the same result as assertEquals() . For the other types, - identity means that the two variables refer to the same object. - - Example : - - ```lua - `s1='toto' - s2='to'..'to' - t1={1,2} - t2={1,2} - luaunit.assertIs(s1,s1) -- ok - luaunit.assertIs(s1,s2) -- ok - luaunit.assertIs(t1,t1) -- ok - luaunit.assertIs(t1,t2) -- fail` - ``` - -* **_AFT.assertNotIs(actual, expected)** - - Assert that two variables are not identical, in the sense that they do not - refer to the same value. See assertIs() for more details.
\ No newline at end of file diff --git a/docs/WriteYourTests/Reference/LuaUnitAssertionFunctions/2_ScientificAssertions.md b/docs/WriteYourTests/Reference/LuaUnitAssertionFunctions/2_ScientificAssertions.md deleted file mode 100644 index 9f80a7a..0000000 --- a/docs/WriteYourTests/Reference/LuaUnitAssertionFunctions/2_ScientificAssertions.md +++ /dev/null @@ -1,48 +0,0 @@ -# Scientific assertions - ->**Note** ->If you need to deal with value minus zero, be very careful because Lua versions -are inconsistent on how they treat the >syntax -0 : it creates either a plus -zero or a minus zero. Multiplying or dividing 0 by -1 also yields inconsistent > -results. The reliable way to create the -0 value is : minusZero = -1 / (1/0). - -* **_AFT.assertIsNaN(value)** - Assert that a given number is a *NaN* (Not a Number), according to the - definition of IEEE-754_ . If provided, *extra_msg* is a string which will - be printed along with the failure message. - -* **_AFT.assertIsPlusInf(value)** - - Assert that a given number is *plus infinity*, according to the definition of - IEEE-754_. If provided, *extra_msg* is a string which will be printed along - with the failure message. - -* **_AFT.assertIsMinusInf(value)** - - Assert that a given number is *minus infinity*, according to the definition of - IEEE-754_. If provided, *extra_msg* is a string which will be printed along - with the failure message. - -* **_AFT.assertIsInf(value)** - - Assert that a given number is *infinity* (either positive or negative), - according to the definition of IEEE-754_. If provided, *extra_msg* is a string - which will be printed along with the failure message. - -* **_AFT.assertIsPlusZero(value)** - - Assert that a given number is *+0*, according to the definition of IEEE-754_. - The verification is done by dividing by the provided number and verifying - that it yields *infinity* . If provided, *extra_msg* is a string which will - be printed along with the failure message. - - Be careful when dealing with *+0* and *-0*, see note above - -* **_AFT.assertIsMinusZero(value)** - - Assert that a given number is *-0*, according to the definition of IEEE-754_. - The verification is done by dividing by the provided number and verifying that - it yields *minus infinity* . If provided, *extra_msg* is a string which will - be printed along with the failure message. - - Be careful when dealing with *+0* and *-0*
\ No newline at end of file diff --git a/docs/WriteYourTests/Reference/LuaUnitAssertionFunctions/3_StringAssertions.md b/docs/WriteYourTests/Reference/LuaUnitAssertionFunctions/3_StringAssertions.md deleted file mode 100644 index a816998..0000000 --- a/docs/WriteYourTests/Reference/LuaUnitAssertionFunctions/3_StringAssertions.md +++ /dev/null @@ -1,38 +0,0 @@ -# String assertions - -Assertions related to string and patterns. - -* **_AFT.assertStrContains(str, sub[, useRe])** - - Assert that a string contains the given substring or pattern. - - By default, substring is searched in the string. If useRe is provided and is - true, sub is treated as a pattern which is searched inside the string str. - -* **_AFT.assertStrIContains(str, sub)** - - Assert that a string contains the given substring, irrespective of the case. - - Not that unlike assertStrcontains(), you can not search for a pattern. - -* **_AFT.assertNotStrContains(str, sub, useRe)** - - Assert that a string does not contain a given substring or pattern. - - By default, substring is searched in the string. If useRe is provided and is - true, sub is treated as a pattern which is searched inside the string str. - -* **_AFT.assertNotStrIContains(str, sub)** - - Assert that a string does not contain the given substring, irrespective of - the case. - - Not that unlike assertNotStrcontains(), you can not search for a pattern. - -* **_AFT.assertStrMatches(str, pattern[, start[, final]])** - - Assert that a string matches the full pattern pattern. - - If start and final are not provided or are nil, the pattern must match the - full string, from start to end. The functions allows to specify the expected - start and end position of the pattern in the string.
\ No newline at end of file diff --git a/docs/WriteYourTests/Reference/LuaUnitAssertionFunctions/4_ErrorAssertions.md b/docs/WriteYourTests/Reference/LuaUnitAssertionFunctions/4_ErrorAssertions.md deleted file mode 100644 index 482b98d..0000000 --- a/docs/WriteYourTests/Reference/LuaUnitAssertionFunctions/4_ErrorAssertions.md +++ /dev/null @@ -1,30 +0,0 @@ -# Error assertions - -Error related assertions, to verify error generation and error messages. - -* **_AFT.assertError(func, ...)** - - Assert that calling functions func with the arguments yields an error. If the function does not yield an error, the assertion fails. - - Note that the error message itself is not checked, which means that this function does not distinguish between the legitimate error that you expect and another error that might be triggered by mistake. - - The next functions provide a better approach to error testing, by checking explicitly the error message content. - ->**Note** ->When testing LuaUnit, switching from assertError() to assertErrorMsgEquals() revealed quite a few bugs! - -* **_AFT.assertErrorMsgEquals(expectedMsg, func, ...)** - - Assert that calling function func will generate exactly the given error message. If the function does not yield an error, or if the error message is not identical, the assertion fails. - - Be careful when using this function that error messages usually contain the file name and line number information of where the error was generated. This is usually inconvenient. To ignore the filename and line number information, you can either use a pattern with assertErrorMsgMatches() or simply check if the message contains a string with assertErrorMsgContains() . - -* **_AFT.assertErrorMsgContains(partialMsg, func, ...)** - - Assert that calling function func will generate an error message containing partialMsg . If the function does not yield an error, or if the expected message is not contained in the error message, the assertion fails. - -* **_AFT.assertErrorMsgMatches(expectedPattern, func, ...)** - - Assert that calling function func will generate an error message matching expectedPattern . If the function does not yield an error, or if the error message does not match the provided pattern the assertion fails. - - Note that matching is done from the start to the end of the error message. Be sure to escape magic all magic characters with % (like -+.?\*) .
\ No newline at end of file diff --git a/docs/WriteYourTests/Reference/LuaUnitAssertionFunctions/5_TypeAssertions.md b/docs/WriteYourTests/Reference/LuaUnitAssertionFunctions/5_TypeAssertions.md deleted file mode 100644 index 843f651..0000000 --- a/docs/WriteYourTests/Reference/LuaUnitAssertionFunctions/5_TypeAssertions.md +++ /dev/null @@ -1,38 +0,0 @@ -# Type assertions - -The following functions all perform type checking on their argument. If the -received value is not of the right type, the failure message will contain the -expected type, the received type and the received value to help you identify -better the problem. - -* **_AFT.assertIsNumber(value)** - - Assert that the argument is a number (integer or float) - -* **_AFT.assertIsString(value)** - - Assert that the argument is a string. - -* **_AFT.assertIsTable(value)** - - Assert that the argument is a table. - -* **_AFT.assertIsBoolean(value)** - - Assert that the argument is a boolean. - -* **_AFT.assertIsFunction(value)** - - Assert that the argument is a function. - -* **_AFT.assertIsUserdata(value)** - - Assert that the argument is a userdata. - -* **_AFT.assertIsThread(value)** - - Assert that the argument is a coroutine (an object with type thread ). - -* **_AFT.assertNotIsThread(value)** - - Assert that the argument is a not coroutine (an object with type thread ).
\ No newline at end of file diff --git a/docs/WriteYourTests/Reference/LuaUnitAssertionFunctions/6_TableAssertions.md b/docs/WriteYourTests/Reference/LuaUnitAssertionFunctions/6_TableAssertions.md deleted file mode 100644 index 8d29988..0000000 --- a/docs/WriteYourTests/Reference/LuaUnitAssertionFunctions/6_TableAssertions.md +++ /dev/null @@ -1,19 +0,0 @@ -# Table assertions - -* **_AFT.assertItemsEquals(actual, expected)** - - Assert that two tables contain the same items, irrespective of their keys. - - This function is practical for example if you want to compare two lists but - where items are not in the same order: - - ```lua - luaunit.assertItemsEquals( {1,2,3}, {3,2,1} ) -- assertion succeeds - ``` - The comparison is not recursive on the items: if any of the items are tables, - they are compared using table equality (like as in assertEquals() ), where the - key matters. - - ```lua - luaunit.assertItemsEquals( {1,{2,3},4}, {4,{3,2,},1} ) -- assertion fails because {2,3} ~= {3,2} - ```
\ No newline at end of file diff --git a/docs/WriteYourTests/Reference/LuaUnitAssertionFunctions/Introduction.md b/docs/WriteYourTests/Reference/LuaUnitAssertionFunctions/Introduction.md deleted file mode 100644 index 2bdf05c..0000000 --- a/docs/WriteYourTests/Reference/LuaUnitAssertionFunctions/Introduction.md +++ /dev/null @@ -1,13 +0,0 @@ -# LuaUnit Assertion Functions - -Follow this section to know which luaUnit assertion functions are available !! - -Section's Table of content : - -* [General Assertions](0_GeneralAssertions.html) -* [Value Assertions](1_ValueAssertions.html) -* [Scientific Assertions](2_ScientificAssertions.html) -* [String Assertions](3_StringAssertions.html) -* [Error Assertions](4_ErrorAssertions.html) -* [Type Assertions](5_TypeAssertions.html) -* [Table Assertions](6_TableAssertions.html)
\ No newline at end of file |