Hello,
I've created some code for doing unit test Schema API based on Junit. There
are some concerns that I would discuss with you.
1. I try to reuse some class from xmlcft framework, especially
org.castor.xmlctf.xmldiff package and subpackages to compare test result. I
intend to add some further functions to compare two in-memory XML nodes
(does not serialize to a file). Do we need to clone to a separate version
(for dependence with xmlcft)?
2. I don't have right to commit on castor and castor-jaxb-2.0. So that I
attach my code to this email.
3. I don't know how to automatically add some metadata in source code like
* @version $Revision: 5951 $ $Date: 2006-04-25 16:09:10 -0600 (Tue, 25 Apr
2006) $
in the header. Do you have a template/tool to do that?. I did some changes
in Code Templates in Eclipse, but it seems that Eclipse doesn't support.
Thank you very much,
Bao
On Fri, May 9, 2008 at 10:14 AM, Werner Guttmann <[EMAIL PROTECTED]>
wrote:
> Hi,
>
> Joachim Grüneis wrote:
> > Hello Bao,
> >
> > I'm not Werner :-) but I think I can answer some of your questions...
> >
> >
> > 2008/5/8 Le Duc Bao <[EMAIL PROTECTED]>:
> >> Hi Werner,
> >>
> >> In last couple of days, I studied the schema API, existent JAXB
> >> source code and also JAXB specification. I found that the existent
> >> schema module hasn't a complement test module. It's good idea to do
> >> some test on existent code to verify the completeness.
> >
> > That is not completely right... there are some tests for SchemaReader
> > and SchemaWriter. There is a subproject with name xmlctf-framework
> > which contains an integration test framework developed for Castor and
> > xmlctf contains the integration tests for Castor XML. If you have a
> > look onto xmlctf/tests/MasterTestSuite/schema/... you fill find all
> > integration tests regarding reading and writing of schema definition
> > files. How these tests are executed can be seen in SchemaTestCase,
> > the main sequence is:
> >
> > File schemaFile = new File(_test.getTestFile() + "/" + _schemaName);
> >
> > String schemaURL = schemaFile.toURL().toString();
> >
> >
> >
> >
> > Schema schema = testReadingSchema(schemaURL);
> >
> > if (schema == null) {
> >
> > return;
> >
> > }
> >
> > testWritingSchema(schemaURL, schema);
> >
> > // Compare marshaled schema to gold file if provided, otherwise to
> > input file
> >
> > compareSchemaFiles(schemaFile);
> >
> > so I expect that SchemaReader and SchemaWriter are tested. BUT I
> > think it will be better if you create plain JUnit tests for your
> > SchemaWriter tests - because:
> >
> >
> > * First of all the implementation of
> > the test framework is very ugly and I would like to get rid of it. *
> > The tests can not easily (nicely) be executed within Eclipse like
> > other JUnit based tests.
> And I will work with Joachim to supply you with a base test class that
> eases things considerably.
>
> > * The tests are meant to test a cycle of
> > read, write and compare the resulting xsd file with the start file...
> > I expect your tests will start with Java code - later annotated Java
> > classes - write a xsd file and compare against a gold file.
> >
> > I do agree that you should build a suite of tests that test creating
> > of schema files starting with Java declarations... to check if all
> > schema definitions you will need later are supported.
> >
> >>
> >> My understanding of your idea is that test cases will be created by
> >> writing some code fragments and expected schema files. Each test
> >> case will execute a code fragment to generate a schema, then
> >> compare this generated schema with expected schema. This approach
> >> will test the corectness of internal schema representation and the
> >> SchemaWriter. Is it right?
> >
> > Yes
> >
> >> Furthermore, I have some stuffs that I need your comments/advices -
> >> Do you agree with my proposal for XML Schema generator
> >> architecture?
> >
> > I have to check older mails regarding it...
> >
> >> - Related to SVN space for my project, will I work dirrectly in
> >> castor-jaxb-2.0 module or will you create a separate module for me?
> >>
> >
> > for all stuff the needs to be extended in the Schema project you will
> > work on Castor itself - for JAXB specific stuff it will be
> > castor-jaxb-2.0 .
> >
> >> - For the coding convention, I remember that Ralf gave me a
> >> document some times before, but I don't keep it in my computer.
> >> Could you give me a pointer for this?
> >
> > You should simply enable checkstyle and you will see the warnings...
> > I adapt files that I really change (more then just a few lines) but I
> > do not reformat class I do not really touch...
> >
> >> Anyway, I keep going on JAXB specification in next few days while
> >> looking for your reply.
> >>
> >> Regards, Bao
> >>
> >>
> >
> > Have fun
> >
> > Joachim
> >
> >>
> >>
> >> On Thu, May 8, 2008 at 7:31 PM, Werner Guttmann
> >> <[EMAIL PROTECTED]> wrote:
> >>
> >>> Hi Bao,
> >>>
> >>> following up your last email about the schema classes, there's
> >>> some ideas how to go about things step by step.
> >>>
> >>> I think it would be a good idea if you added your code fragments
> >>> (that demonstrate and investigate the completeness of the
> >>> existing schema classes) to e.g. the test case of the 'schema'
> >>> module.
> >>>
> >>> I have been talking to Joachim the other day, and we think that
> >>> we could come up with a base test case class that takes a Schema
> >>> object instance, writes it to a physical XML schema file (using
> >>> SchemaWriter) and compares it with a gold XML schema file.
> >>>
> >>> Based upon this test case, you could create one test case after
> >>> the other and add them to src/test/java and src/test/resources of
> >>> the schema module.
> >>>
> >>> In terms of proceeding on the complexity side of things, I'd
> >>> start with simple things such as adding one complex type, one
> >>> global element definition to an XML schema, and then take it from
> >>> there. If you had a look at the JAXB specification, you'll find
> >>> plenty of references in terms of what XML schema artefacts you
> >>> will have to be able to produce (and serialize).
> >>>
> >>> Let me know whether this approach is fine for you, and whether
> >>> you have any additional thoughts.
> >>>
> >>> Regards Werner
> >>>
> >>
> >>
> >> -- Le Duc Bao
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> > http://xircles.codehaus.org/manage_email
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
--
Le Duc Bao
