Use TestNG for testing purposes?

[fge]

I see JUnit 3.x is used.

TestNG is (imho) a better tool for that. Consider this:

https://github.com/fge/json-schema-validator/blob/master/src/test/java/com/github/fge/jsonschema/syntax/AbstractSyntaxCheckerTest.java

In particular, note that there is a @DataProvider and it is used in the test:

    @Test(dataProvider = "getData", invocationCount = 5, threadPoolSize = 3)

This tests not only against all of the data provided by the data provider, but also does multithreaded testing.

Which means you can test at very low levels with ease: just create the appropriate data provider.

[reinert]

Yeah, i was planning to use TestNG. Undoubtedly better. I'm not very experiencied using it, so feel free to modify the tests here.

[reinert]

How do you suggest validating an JsonSchema generated object against a predefined json-schema string.

For instance, i want to assert if the output generated in the ProductTest.java is equivalent with the json-schema presented in the official website at http://json-schema.org/example1.html.

[fge]

I wouldn't suggest testing string-wise. Generate a JsonNode from your schema, load a resource file as a JsonNode and use .equals().

[reinert]

It would be another hard work to build a schema from a resource. And at my point of view, useful only for testing. Does it really worth?

[fge]

I don't get it: don't you generate a JSON representation of schemas as a JsonNode already?

Loading a file as JSON is easy enough (see JsonLoader in my project).

[reinert]

That's the point. At this moment i'm not using a underlying JsonNode representation. I'm using POJOs. My JsonSchema class is a POJO, as well as my HyperSchema class.

Maybe it's time to stabilish an common interface for our projects concerning these entities.

[reinert]

Explaining my model:

- JsonSchema declares a extensive interface common to all possible versions of json-schema. - AbstractJsonSchema is the general implementation of it. Note that in some methods specific to a single version of json-schema it throws UnsupportedOperationException. - JsonSchemaV4 implements the draft04 of json-schema. It simply exenteds AbstractJsonSchema and implements the specifc methods to this version. Take as an example the required atribute. At v3 it was a boolean inside the property. At v4 it is an array outside the properties. So my JsonSchemaV4 implements required as an ArrayList<String>, while JsonSchemaV3 (if present) would implement it as a Boolean.

[fge]

Maybe it's time to stabilish an common interface for our projects concerning these entities.

If, by this, you mean having a common model for both of our projects, then this is a very nice goal, however I am not there yet. I am attempting to do that currently, but for this I need to code more, check that the model is perennial, and port ALL keywords to this new model (ouch).

One thing: don't throw an UnsupportedOperationException, this is an unchecked exception. And by the way, exceptions are also a thing which should be common.

[reinert]

having a common model for both of our projects

Yeah, that's what i meant.

exceptions are also a thing which should be common.

Right. That's the exception i use when sketching a composite model (or similar). But for permanent purposes it's necessary to create an UnsupportedVersionException or something like that.

[reinert]

I don't get it: don't you generate a JSON representation of schemas as a JsonNode already?

Ok fge. I've made a new Generator using ObjectNode for represent the JSON Schema. I think i'll deprecate the JsonSchema Pojo that i've be using so far.

Now we can easily test the generated JSON Schemas against predefined schemas as resources since they are now Jackson's JsonNodes.

[fge]

Note: I didn't say that a POJO representation was a bad thing ;) It is just that it makes sense to have a JSON representation of it (would it be only to share generated schemas: everyone can read JSON), and JsonNode is the idea medium for that.

[reinert]

Actually, for this case, JsonNode is far way better because it's more flexible and allowed me improve a lot the class design.

I'll escape those annoying exceptions cause it won't exist a fixed interface anymore. And I think that using JsonNode will allow me to implement the Visitor Pattern, making the design even more extensible, with no headaches of reading previously implemented code. My idea is, for each new arising feature, you just need to implement a visitor that handles it, and register this visitor in the factory. The factory will automatically handle the creation of the schema JsonNode using all the visitors registered in itself.

[fge]

Remember what I said about design patterns, don't try and fit a square peg in a round hole ;) The visitor patern may, or may not, fit.

[reinert]

Actually, I'm not focused on "forcing" this design's implementation. Rather, I'm focused on achieving it's idea:

for each new arising feature, you just need to implement a visitor that handles it, and register this visitor in the factory. The factory will automatically handle the creation of the schema JsonNode using all the visitors registered in itself.

This way, the project's design will be 'closed for modification and opened for extension'

[fge]

Well, I do this for schema keywords -- except I don't use visitors, I can't (I need state). Look at KeywordValidators in my project, for instance.

Meh, this class will disappear soon, but this is the same idea.