summaryrefslogtreecommitdiff
path: root/json-glib/tests
Commit message (Collapse)AuthorAgeFilesLines
...
* 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