Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Add acceptance test framework for better end-to-end testing #10

Closed
joelittlejohn opened this issue Jun 23, 2013 · 3 comments
Closed

Add acceptance test framework for better end-to-end testing #10

joelittlejohn opened this issue Jun 23, 2013 · 3 comments

Comments

@joelittlejohn
Copy link
Owner

Original author: joelittl...@gmail.com (January 14, 2011 15:38:49)

Create a framework that allows end-to-end acceptance testing of jsonschema2pojo via its maven plugin.

See this clone:
https://matthewgilliard-maven-plugin-testing.googlecode.com/hg/

Original issue: http://code.google.com/p/jsonschema2pojo/issues/detail?id=10

@joelittlejohn
Copy link
Owner Author

From joelittl...@gmail.com on February 13, 2011 21:34:17
Having used the strategy applied in the testing clone on another project I'm considering going a different route with this one now. I've been working on a more light-weight mechanism to generate and compile test types which may be more appropriate.

Option 1: Integration testing by creating maven projects, using an artificially constructed repo and the maven Verifier API.

Pros: Full e2e test
Cons: Very slow. Difficult to run tests within Eclipse. Many additional artifacts required when defining new tests.

Option 2: Direct invocation of the plugin from IT test, combined with commons JCI or JSR-199 for compilation.

Pros: Very fast. Independent tests (no maven settings/local repo setup required) and
runnable in Eclipse. Much easier to record test coverage.
Cons: Not a full e2e test (doesn't invoke the plugin as part of a maven lifecycle)

In day-to-day development, Option 2 is a lot easier to work with. The only part that's missing here is invocation as part of a maven lifecycle with maven mapping parameter values onto plugin field values (which should, arguably, be out of scope anyway). It could be good to combine both of these strategies, with the the main body of integration tests being implemented as per Option 2, with Option 1 being used as a sanity check on the plugin.

I'm currently waiting on a release of Commons JCI before pushing to trunk (http://markmail.org/message/uu3j3zr6ro4l5lzo).

@joelittlejohn
Copy link
Owner Author

From joelittl...@gmail.com on February 22, 2011 12:05:48
Works great but we're still waiting on that commons-jci release - the current trunk requires a commons-jci 1.1-SNAPSHOT to be present in your local repo :(

Targeting to have completed any remaining tasks on this for 0.1.7. If there's still no publicly available, working Commons JCI release by then, then we'll build our own SNAPSHOT and add it to a temporary repo hosted somwwhere within this project's googlecode site.

@joelittlejohn
Copy link
Owner Author

From joelittl...@gmail.com on February 27, 2011 22:41:27
Commons JCI release is taking some time to arrive. I've uploaded a snapshot build of commons-jci (built from r1070117) into the wiki repo here:

http://wiki.jsonschema2pojo.googlecode.com/hg/repository

Once commons-jci makes another release we can remove this workaround. Marking as fixed since we have a portable build again.

flibbertigibbet added a commit to flibbertigibbet/jsonschema2pojo that referenced this issue Jun 14, 2016
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

1 participant