summaryrefslogtreecommitdiff
path: root/json-glib/tests
Commit message (Collapse)AuthorAgeFilesLines
...
* Allow NULL as a value for strings, arrays and objectsEmmanuele Bassi2010-06-161-0/+4
| | | | | We should not warn when asking for a string, array or object if the contents were 'null'.
* parser: Add MISSING_COLON errorEmmanuele Bassi2010-03-191-1/+2
| | | | | | We identify a missing ':' separator between an object member name and its value, so it would be a good thing to actually have an error code for that.
* parser: Return specific error codesEmmanuele Bassi2010-03-191-9/+9
| | | | | | | | | The JsonScanner error reporting mechanism, which is basically GScanner's, sucks beyond belief. In order to report an error code we need to store it inside the JsonParser private structure and then use it when creating the GError inside the error handler. This, frankly, is quite stupid.
* parser-test: Add a case for double parsing in JsonObjectEmmanuele Bassi2010-03-181-1/+2
|
* parser-test: Add a complex nested object testEmmanuele Bassi2010-03-181-1/+20
| | | | | The nested object test should use something that's really complex: an object with a nested array and nested object definitions.
* tests: Add another trailing comma invalid testEmmanuele Bassi2010-03-051-1/+2
|
* tests: Add negative testsEmmanuele Bassi2010-03-011-0/+53
| | | | Verify that invalid JSON will trigger a parser error.
* build: Enable maintainer flags when compiling testsEmmanuele Bassi2010-01-021-1/+1
| | | | | The tests should be compiled under the same flags as the rest of the library.
* tests: Clean up JsonGenerator test suiteEmmanuele Bassi2010-01-021-120/+25
| | | | Use typed accessors instead of using GValues all around.
* tests: Verify Array.get_elements()Emmanuele Bassi2010-01-011-5/+17
| | | | | While verifying Array.foreach() we should also verify that the list we are iterating on is the same returned by the get_elements() method.
* tests: Re-enable the nested object generator unitEmmanuele Bassi2009-12-291-46/+56
| | | | | | Use the JSON object example inside the RFC 4627 to verify that the JsonGenerator creates the right output. This is now possible as we garantee the order of a JsonObject members.
* tests: Move Parser and Generator testsEmmanuele Bassi2009-12-293-9/+1006
| | | | | | | | | | Use the json-glib/tests directory for testing the data structures of JSON-GLib: node, object, array, parser and generator. The tests/ directory should be used for complex test cases, like the GObject and GBoxed integration - but the goal is to remove the top-level tests/ directory altogether, since the conformance test suite should be built along the json-glib/ directory.
* build: Clean up the build environmentEmmanuele Bassi2009-10-271-4/+8
| | | | | | | | | | | | | | | | Some of the rules can be moved into their own files to be included when needed, like: • silent rules (QUIET_*) • glib-mkenums rules • glib-genmarshal rules Also, the test suite rules should be moved from the top-level of the project into the build/autotools directory and then included only where it makes sense. This requires changing most of the build system to use the new files layout.
* [node] Add HOLDS macros for quick type checkingEmmanuele Bassi2009-09-281-1/+1
| | | | JsonNode should mimick GValue's API and have macros for easy type checking
* [tests] Add a test case for Object members with empty stringsEmmanuele Bassi2009-09-281-0/+13
| | | | | | | Both the Object API and the Parser should not choke on members with empty strings as their value. The Object should just have a member associated with a JSON_NODE_VALUE node type and an empty string as the contents.
* [tests] Include json-glib.hEmmanuele Bassi2009-08-123-3/+3
| | | | Do not include json-types.h, use the correct global include.
* Auto-promote integer types to G_TYPE_INT64Emmanuele Bassi2009-08-123-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The JSON RFC does not specify the size of the integer type, thus implicitly falling back to machine-size. This would all be fine and dandy if some demented Web Developer (and I use the term "developer" *very much* loosely) did not decide to use integers to store unique identifiers for objects; obviously, you can't have more than 2^32-1 status messages in a database with millions of users who update their status multiple times per day. Right, Twitter? Anyway, some languages do a type auto-promotion from Integer to Long, thus pushing the limit of allowed positive values -- until the next integer overflow, that is. C, and GLib, do not do that transparently for us so we need to: - always use gint64 when parsing a JSON data stream using JsonScanner - move all the Node, Object and Array APIs to gint64 - auto-promote G_TYPE_INT to G_TYPE_INT64 when setting a GValue manually - auto-promote and auto-demote G_TYPE_INT properties when (de)serializing GObjects. The GLib types used internally by JSON-GLib are, thus: integer -> G_TYPE_INT64 boolean -> G_TYPE_BOOLEAN float -> G_TYPE_DOUBLE string -> G_TYPE_STRING
* [node] Make JsonNode completely privateEmmanuele Bassi2009-06-091-4/+4
| | | | | | | | | | The JsonNode structure has always been meant to be completely opaque; we indirectly exposed the :type member, but only for access through the JSON_NODE_TYPE() macro. Since that macro has become a proxy for the json_node_get_node_type() function we can safely move everything into a private, uninstalled header file and let JsonNode be completely opaque to the developer.
* Add JsonArray iteration functionEmmanuele Bassi2009-05-171-0/+48
| | | | | | Similarly to commit 3057a172 for JsonObject, the newly added json_array_foreach_element() iterates over a JSON array data type.
* Add JsonObject iteration functionEmmanuele Bassi2009-05-161-0/+57
| | | | | The json_object_foreach_member() function iterates over a JsonObject data type.
* Update after the json_object_add_member() deprecationEmmanuele Bassi2009-04-172-3/+3
| | | | | | | Since json_object_add_member() has been deprecated and it's using a gcc compiler attribute to loudly complain while compiling the library, we should restore the sanity and use json_object_set_member() instead.
* [node] Do not overwrite when copyingEmmanuele Bassi2009-04-141-2/+43
| | | | | | | | | | | | | | | | | Bug 1353 - Copying JSON_NODE_VALUE nodes unreliable at best When copying a JsonNode to another we do an implicit memcpy using: *copy = *src Which works well enough with pointers, but makes a mess out of the value-based nodes. We should just copy the type of the original JsonNode and leave the rest to the switch() block. In order to catch potential regressions, we also need a more thorough test unit for the JsonNode copy operation.
* Add value testing to the JsonNode unitEmmanuele Bassi2008-03-091-0/+29
| | | | Test the GValue API for storing fundamental types into a JsonNode.
* Add JsonObject test unitEmmanuele Bassi2008-03-052-6/+73
| | | | | Use a similar test unit as the JsonArray one, testing creation, empty objects, addition and removal of members.
* Add element removal unit to the Array testEmmanuele Bassi2008-03-051-0/+12
| | | | | | Remove the json_array_remove_element() call from the add-element test unit and set up a separate test case for the element removal. This keeps the test cases clean.
* Add array-test to the JSON-GLib types unit testsEmmanuele Bassi2008-03-022-3/+57
| | | | | This simple unit will test the JsonArray API, as part of the coverage test for the JSON-GLib types.
* Add a JsonNode copy test unitEmmanuele Bassi2008-03-021-0/+15
| | | | | The test unit copies a NULL JsonNode and checks that the copy and the original nodes are equivalent.
* Add initial test suite support using GLib's new testing frameworkEmmanuele Bassi2008-03-012-0/+42
GLib 2.15 added a new test unit framework to the GLib API. It allows integrating unit testing into GLib and GObject based libraries and applications. It requires a specially crafter Makefile holding a set of declarations, which must be included into the project own Makefile templates; then it is possible to drop tests inside a subdirectory, which will be built after the library or application, and executed upon "make check". At the moment, there is a simple test for the JsonNode API, with a single unit for the "null" node type.
View Lorry Controller Status