Subsystem testing harness

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Subsystem testing harness

kkhan
There is now a testing harness for testing subsystem parsing, that the operations work, that the model gets updated and services get installed in the service container as expected.

If your subsystem is not totally self contained, the harness provided makes it easy to
* Install services your subsystem depends on manually
* Add socket bindings, paths and system properties used by your subsystem
* Add parsers and other subsystem extensions required by your subsystem

It lives in https://github.com/jbossas/jboss-as/tree/master/subsystem-test and contains some examples/tests of the harness itself in https://github.com/jbossas/jboss-as/tree/master/subsystem-test/src/test.

To see it used in the wild, take a look at https://github.com/jbossas/jboss-as/blob/master/jmx/src/test/java/org/jboss/as/jmx/JMXSubsystemTestCase.java. As you can see here it
* checks that the model exists:
https://github.com/jbossas/jboss-as/blob/master/jmx/src/test/java/org/jboss/as/jmx/JMXSubsystemTestCase.java#L180
* actually bootstraps the controller and uses the services installed by the JMX service (the jmx connector in this case):
https://github.com/jbossas/jboss-as/blob/master/jmx/src/test/java/org/jboss/as/jmx/JMXSubsystemTestCase.java#L186

The JMX subsystem is trivial, but when writing this test I found a few minor bugs. So if you are a subsystem maintainer, I'd highly recommend using this to test your subsystem properly in isolation.

This is based on the stuff that was in the subsystem maven artifact, which now in turn will be based on jboss-as-subsystem-test instead. So, if you find some problems with it try to add to the API rather than changing it, or check with me.
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Subsystem testing harness

David Bosschaert
Awesome! I'm going to have a play with that today. Was looking for
something like this for a while.

Cheers,

David

On 18/07/2011 18:05, Kabir Khan wrote:

> There is now a testing harness for testing subsystem parsing, that the operations work, that the model gets updated and services get installed in the service container as expected.
>
> If your subsystem is not totally self contained, the harness provided makes it easy to
> * Install services your subsystem depends on manually
> * Add socket bindings, paths and system properties used by your subsystem
> * Add parsers and other subsystem extensions required by your subsystem
>
> It lives in https://github.com/jbossas/jboss-as/tree/master/subsystem-test and contains some examples/tests of the harness itself in https://github.com/jbossas/jboss-as/tree/master/subsystem-test/src/test.
>
> To see it used in the wild, take a look at https://github.com/jbossas/jboss-as/blob/master/jmx/src/test/java/org/jboss/as/jmx/JMXSubsystemTestCase.java. As you can see here it
> * checks that the model exists:
> https://github.com/jbossas/jboss-as/blob/master/jmx/src/test/java/org/jboss/as/jmx/JMXSubsystemTestCase.java#L180
> * actually bootstraps the controller and uses the services installed by the JMX service (the jmx connector in this case):
> https://github.com/jbossas/jboss-as/blob/master/jmx/src/test/java/org/jboss/as/jmx/JMXSubsystemTestCase.java#L186
>
> The JMX subsystem is trivial, but when writing this test I found a few minor bugs. So if you are a subsystem maintainer, I'd highly recommend using this to test your subsystem properly in isolation.
>
> This is based on the stuff that was in the subsystem maven artifact, which now in turn will be based on jboss-as-subsystem-test instead. So, if you find some problems with it try to add to the API rather than changing it, or check with me.
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Subsystem testing harness

kkhan
Let me know how you get along. The test harness uses a flat classpath, with no modules. I think this is fine for most subsystems but I'm not sure how that will play out in OSGi land.
On 19 Jul 2011, at 09:31, David Bosschaert wrote:

> Awesome! I'm going to have a play with that today. Was looking for
> something like this for a while.
>
> Cheers,
>
> David
>
> On 18/07/2011 18:05, Kabir Khan wrote:
>> There is now a testing harness for testing subsystem parsing, that the operations work, that the model gets updated and services get installed in the service container as expected.
>>
>> If your subsystem is not totally self contained, the harness provided makes it easy to
>> * Install services your subsystem depends on manually
>> * Add socket bindings, paths and system properties used by your subsystem
>> * Add parsers and other subsystem extensions required by your subsystem
>>
>> It lives in https://github.com/jbossas/jboss-as/tree/master/subsystem-test and contains some examples/tests of the harness itself in https://github.com/jbossas/jboss-as/tree/master/subsystem-test/src/test.
>>
>> To see it used in the wild, take a look at https://github.com/jbossas/jboss-as/blob/master/jmx/src/test/java/org/jboss/as/jmx/JMXSubsystemTestCase.java. As you can see here it
>> * checks that the model exists:
>> https://github.com/jbossas/jboss-as/blob/master/jmx/src/test/java/org/jboss/as/jmx/JMXSubsystemTestCase.java#L180
>> * actually bootstraps the controller and uses the services installed by the JMX service (the jmx connector in this case):
>> https://github.com/jbossas/jboss-as/blob/master/jmx/src/test/java/org/jboss/as/jmx/JMXSubsystemTestCase.java#L186
>>
>> The JMX subsystem is trivial, but when writing this test I found a few minor bugs. So if you are a subsystem maintainer, I'd highly recommend using this to test your subsystem properly in isolation.
>>
>> This is based on the stuff that was in the subsystem maven artifact, which now in turn will be based on jboss-as-subsystem-test instead. So, if you find some problems with it try to add to the API rather than changing it, or check with me.
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Subsystem testing harness

David Bosschaert
Hi Kabir,

Was wondering, is there a way to test the subsystem write operation
without actually starting the whole thing up?
I see that the JMXSubsystemTestCase.testParseAndMarshalModel() does a
read-write test, but it also starts up the system which is a bit more
heavyweight than I really want.

I guess what I'm looking for would allow me to do something like this:
   String subsystemXml = ...
   List<ModelNode> operations = parse(subsystemXml);
   String writtenXml = write(operations);
   assertEquivalent(subsystemXML, writtenXml)
   // btw the XML doesn't have to be exactly the same, but logically
equivalent, assertEquivalent() should take this into account

Cheers,

David

On 19/07/2011 10:10, Kabir Khan wrote:

> Let me know how you get along. The test harness uses a flat classpath, with no modules. I think this is fine for most subsystems but I'm not sure how that will play out in OSGi land.
> On 19 Jul 2011, at 09:31, David Bosschaert wrote:
>
>> Awesome! I'm going to have a play with that today. Was looking for
>> something like this for a while.
>>
>> Cheers,
>>
>> David
>>
>> On 18/07/2011 18:05, Kabir Khan wrote:
>>> There is now a testing harness for testing subsystem parsing, that the operations work, that the model gets updated and services get installed in the service container as expected.
>>>
>>> If your subsystem is not totally self contained, the harness provided makes it easy to
>>> * Install services your subsystem depends on manually
>>> * Add socket bindings, paths and system properties used by your subsystem
>>> * Add parsers and other subsystem extensions required by your subsystem
>>>
>>> It lives in https://github.com/jbossas/jboss-as/tree/master/subsystem-test and contains some examples/tests of the harness itself in https://github.com/jbossas/jboss-as/tree/master/subsystem-test/src/test.
>>>
>>> To see it used in the wild, take a look at https://github.com/jbossas/jboss-as/blob/master/jmx/src/test/java/org/jboss/as/jmx/JMXSubsystemTestCase.java. As you can see here it
>>> * checks that the model exists:
>>> https://github.com/jbossas/jboss-as/blob/master/jmx/src/test/java/org/jboss/as/jmx/JMXSubsystemTestCase.java#L180
>>> * actually bootstraps the controller and uses the services installed by the JMX service (the jmx connector in this case):
>>> https://github.com/jbossas/jboss-as/blob/master/jmx/src/test/java/org/jboss/as/jmx/JMXSubsystemTestCase.java#L186
>>>
>>> The JMX subsystem is trivial, but when writing this test I found a few minor bugs. So if you are a subsystem maintainer, I'd highly recommend using this to test your subsystem properly in isolation.
>>>
>>> This is based on the stuff that was in the subsystem maven artifact, which now in turn will be based on jboss-as-subsystem-test instead. So, if you find some problems with it try to add to the API rather than changing it, or check with me.
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Subsystem testing harness

kkhan
You need to start up MSC to get reference to the model controller since that is the only real way to get hold of the model controller. I guess you are saying you want the model changes and associated persistence of the xml to happen when invoking your ops, but not the installation of services?
On 20 Jul 2011, at 12:23, David Bosschaert wrote:

> Hi Kabir,
>
> Was wondering, is there a way to test the subsystem write operation without actually starting the whole thing up?
> I see that the JMXSubsystemTestCase.testParseAndMarshalModel() does a read-write test, but it also starts up the system which is a bit more heavyweight than I really want.
>
> I guess what I'm looking for would allow me to do something like this:
>  String subsystemXml = ...
>  List<ModelNode> operations = parse(subsystemXml);
>  String writtenXml = write(operations);
>  assertEquivalent(subsystemXML, writtenXml)
>  // btw the XML doesn't have to be exactly the same, but logically equivalent, assertEquivalent() should take this into account
>
> Cheers,
>
> David
>
> On 19/07/2011 10:10, Kabir Khan wrote:
>> Let me know how you get along. The test harness uses a flat classpath, with no modules. I think this is fine for most subsystems but I'm not sure how that will play out in OSGi land.
>> On 19 Jul 2011, at 09:31, David Bosschaert wrote:
>>
>>> Awesome! I'm going to have a play with that today. Was looking for
>>> something like this for a while.
>>>
>>> Cheers,
>>>
>>> David
>>>
>>> On 18/07/2011 18:05, Kabir Khan wrote:
>>>> There is now a testing harness for testing subsystem parsing, that the operations work, that the model gets updated and services get installed in the service container as expected.
>>>>
>>>> If your subsystem is not totally self contained, the harness provided makes it easy to
>>>> * Install services your subsystem depends on manually
>>>> * Add socket bindings, paths and system properties used by your subsystem
>>>> * Add parsers and other subsystem extensions required by your subsystem
>>>>
>>>> It lives in https://github.com/jbossas/jboss-as/tree/master/subsystem-test and contains some examples/tests of the harness itself in https://github.com/jbossas/jboss-as/tree/master/subsystem-test/src/test.
>>>>
>>>> To see it used in the wild, take a look at https://github.com/jbossas/jboss-as/blob/master/jmx/src/test/java/org/jboss/as/jmx/JMXSubsystemTestCase.java. As you can see here it
>>>> * checks that the model exists:
>>>> https://github.com/jbossas/jboss-as/blob/master/jmx/src/test/java/org/jboss/as/jmx/JMXSubsystemTestCase.java#L180
>>>> * actually bootstraps the controller and uses the services installed by the JMX service (the jmx connector in this case):
>>>> https://github.com/jbossas/jboss-as/blob/master/jmx/src/test/java/org/jboss/as/jmx/JMXSubsystemTestCase.java#L186
>>>>
>>>> The JMX subsystem is trivial, but when writing this test I found a few minor bugs. So if you are a subsystem maintainer, I'd highly recommend using this to test your subsystem properly in isolation.
>>>>
>>>> This is based on the stuff that was in the subsystem maven artifact, which now in turn will be based on jboss-as-subsystem-test instead. So, if you find some problems with it try to add to the API rather than changing it, or check with me.
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Subsystem testing harness

David Bosschaert
On 20/07/2011 15:34, Kabir Khan wrote:
> You need to start up MSC to get reference to the model controller since that is the only real way to get hold of the model controller. I guess you are saying you want the model changes and associated persistence of the xml to happen when invoking your ops, but not the installation of services?

Yes, from a unit testing point of view that would be nice :)

Currently I can test the reading part as a unit without causing any side
effects in the system, i.e. XML -> ModelNodes
It would be great to be able to test the writing part as a unit too:
ModelNodes -> XML

Cheers,

David
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Subsystem testing harness

kkhan
My https://github.com/kabir/jboss-as/commits/parsing-harness contains some adjustements.

https://github.com/kabir/jboss-as/commit/8f6538850604e0633c34c27d6fa70bb81dc180de#L6R108
shows how to invoke the ops without doing the RUNTIME part of the operation handlers, i.e. services will not get installed.

https://github.com/kabir/jboss-as/commit/8f6538850604e0633c34c27d6fa70bb81dc180de#L6R186
shows how to just marshall a raw model to xml.


On 20 Jul 2011, at 16:40, David Bosschaert wrote:

> On 20/07/2011 15:34, Kabir Khan wrote:
>> You need to start up MSC to get reference to the model controller since that is the only real way to get hold of the model controller. I guess you are saying you want the model changes and associated persistence of the xml to happen when invoking your ops, but not the installation of services?
>
> Yes, from a unit testing point of view that would be nice :)
>
> Currently I can test the reading part as a unit without causing any side effects in the system, i.e. XML -> ModelNodes
> It would be great to be able to test the writing part as a unit too: ModelNodes -> XML
>
> Cheers,
>
> David


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Subsystem testing harness

David Bosschaert
Nice, thanks Kabir!

I'll play around with that soon!

David

On 21/07/2011 15:37, Kabir Khan wrote:

> My https://github.com/kabir/jboss-as/commits/parsing-harness contains some adjustements.
>
> https://github.com/kabir/jboss-as/commit/8f6538850604e0633c34c27d6fa70bb81dc180de#L6R108
> shows how to invoke the ops without doing the RUNTIME part of the operation handlers, i.e. services will not get installed.
>
> https://github.com/kabir/jboss-as/commit/8f6538850604e0633c34c27d6fa70bb81dc180de#L6R186
> shows how to just marshall a raw model to xml.
>
>
> On 20 Jul 2011, at 16:40, David Bosschaert wrote:
>
>> On 20/07/2011 15:34, Kabir Khan wrote:
>>> You need to start up MSC to get reference to the model controller since that is the only real way to get hold of the model controller. I guess you are saying you want the model changes and associated persistence of the xml to happen when invoking your ops, but not the installation of services?
>> Yes, from a unit testing point of view that would be nice :)
>>
>> Currently I can test the reading part as a unit without causing any side effects in the system, i.e. XML ->  ModelNodes
>> It would be great to be able to test the writing part as a unit too: ModelNodes ->  XML
>>
>> Cheers,
>>
>> David

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Subsystem testing harness

kkhan
I'll push it to master once I get the ok (since I had to change the controller slightly)
On 21 Jul 2011, at 16:43, David Bosschaert wrote:

> Nice, thanks Kabir!
>
> I'll play around with that soon!
>
> David
>
> On 21/07/2011 15:37, Kabir Khan wrote:
>> My https://github.com/kabir/jboss-as/commits/parsing-harness contains some adjustements.
>>
>> https://github.com/kabir/jboss-as/commit/8f6538850604e0633c34c27d6fa70bb81dc180de#L6R108
>> shows how to invoke the ops without doing the RUNTIME part of the operation handlers, i.e. services will not get installed.
>>
>> https://github.com/kabir/jboss-as/commit/8f6538850604e0633c34c27d6fa70bb81dc180de#L6R186
>> shows how to just marshall a raw model to xml.
>>
>>
>> On 20 Jul 2011, at 16:40, David Bosschaert wrote:
>>
>>> On 20/07/2011 15:34, Kabir Khan wrote:
>>>> You need to start up MSC to get reference to the model controller since that is the only real way to get hold of the model controller. I guess you are saying you want the model changes and associated persistence of the xml to happen when invoking your ops, but not the installation of services?
>>> Yes, from a unit testing point of view that would be nice :)
>>>
>>> Currently I can test the reading part as a unit without causing any side effects in the system, i.e. XML ->  ModelNodes
>>> It would be great to be able to test the writing part as a unit too: ModelNodes ->  XML
>>>
>>> Cheers,
>>>
>>> David
>


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Subsystem testing harness

kkhan
In reply to this post by David Bosschaert
It has changed slightly after some comments from Brian and Emanuel. New commit is here: https://github.com/kabir/jboss-as/commit/e5144e1c6832756408f9385ed21b4df6abe49a33

AdditionalInitialization.getType() == MANAGEMENT forces the non-install of services now
On 21 Jul 2011, at 16:43, David Bosschaert wrote:

> Nice, thanks Kabir!
>
> I'll play around with that soon!
>
> David
>
> On 21/07/2011 15:37, Kabir Khan wrote:
>> My https://github.com/kabir/jboss-as/commits/parsing-harness contains some adjustements.
>>
>> https://github.com/kabir/jboss-as/commit/8f6538850604e0633c34c27d6fa70bb81dc180de#L6R108
>> shows how to invoke the ops without doing the RUNTIME part of the operation handlers, i.e. services will not get installed.
>>
>> https://github.com/kabir/jboss-as/commit/8f6538850604e0633c34c27d6fa70bb81dc180de#L6R186
>> shows how to just marshall a raw model to xml.
>>
>>
>> On 20 Jul 2011, at 16:40, David Bosschaert wrote:
>>
>>> On 20/07/2011 15:34, Kabir Khan wrote:
>>>> You need to start up MSC to get reference to the model controller since that is the only real way to get hold of the model controller. I guess you are saying you want the model changes and associated persistence of the xml to happen when invoking your ops, but not the installation of services?
>>> Yes, from a unit testing point of view that would be nice :)
>>>
>>> Currently I can test the reading part as a unit without causing any side effects in the system, i.e. XML ->  ModelNodes
>>> It would be great to be able to test the writing part as a unit too: ModelNodes ->  XML
>>>
>>> Cheers,
>>>
>>> David
>


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Subsystem testing harness

David Bosschaert
Hi Kabir,

It works for me. It allows for the following generic code to test
read+write of any subsystem :)
     String subsystemXML = "..."; // my subsystem XML
     KernelServices services = installInController(new
EmptyAdditionalInitialization() {
         @Override
         public Type getType() {
             return Type.MANAGEMENT;
         }
     }, subsystemXml);
     ModelNode model = services.readWholeModel();
     String marshalled = outputModel(model);
     Assert.assertEquals(normalizeXML(subsystemXml),
normalizeXML(marshalled));

Note that I used a normalizeXML method to treat the XML strings before
using string compare to evaluate them. It takes into account things like
normalizing attribute order, ignoring comments and pretty-printing
elements to make sure that they are organized the same way. It might be
an idea to add normalizeXML() to AbstractSubsystemTest. I've pasted it
below.

Cheers & thanks!

David

/**
  * Normalize and pretty-print XML so that it can be compared using
string compare.
  * The following code does the following:
  * - Removes comments
  * - Makes sure attributes are ordered consistently
  * - Trims every element
  * - Pretty print the document
  * @param xml The XML to be normalized
  * @return The equivalent XML, but now normalized
  */
private String normalizeXML(String xml) throws Exception {
     // Remove all white space adjoining tags ("trim all elements")
     xml = xml.replaceAll("\\s*<", "<");
     xml = xml.replaceAll(">\\s*", ">");

     DOMImplementationRegistry registry =
DOMImplementationRegistry.newInstance();
     DOMImplementationLS domLS = (DOMImplementationLS)
registry.getDOMImplementation("LS");
     LSParser lsParser =
domLS.createLSParser(DOMImplementationLS.MODE_SYNCHRONOUS, null);

     LSInput input = domLS.createLSInput();
     input.setStringData(xml);
     Document document = lsParser.parse(input);

     LSSerializer lsSerializer = domLS.createLSSerializer();
     lsSerializer.getDomConfig().setParameter("comments", Boolean.FALSE);
     lsSerializer.getDomConfig().setParameter("format-pretty-print",
Boolean.TRUE);
     return lsSerializer.writeToString(document);
}


On 21/07/2011 16:16, Kabir Khan wrote:

> It has changed slightly after some comments from Brian and Emanuel. New commit is here: https://github.com/kabir/jboss-as/commit/e5144e1c6832756408f9385ed21b4df6abe49a33
>
> AdditionalInitialization.getType() == MANAGEMENT forces the non-install of services now
> On 21 Jul 2011, at 16:43, David Bosschaert wrote:
>
>> Nice, thanks Kabir!
>>
>> I'll play around with that soon!
>>
>> David
>>
>> On 21/07/2011 15:37, Kabir Khan wrote:
>>> My https://github.com/kabir/jboss-as/commits/parsing-harness contains some adjustements.
>>>
>>> https://github.com/kabir/jboss-as/commit/8f6538850604e0633c34c27d6fa70bb81dc180de#L6R108
>>> shows how to invoke the ops without doing the RUNTIME part of the operation handlers, i.e. services will not get installed.
>>>
>>> https://github.com/kabir/jboss-as/commit/8f6538850604e0633c34c27d6fa70bb81dc180de#L6R186
>>> shows how to just marshall a raw model to xml.
>>>
>>>
>>> On 20 Jul 2011, at 16:40, David Bosschaert wrote:
>>>
>>>> On 20/07/2011 15:34, Kabir Khan wrote:
>>>>> You need to start up MSC to get reference to the model controller since that is the only real way to get hold of the model controller. I guess you are saying you want the model changes and associated persistence of the xml to happen when invoking your ops, but not the installation of services?
>>>> Yes, from a unit testing point of view that would be nice :)
>>>>
>>>> Currently I can test the reading part as a unit without causing any side effects in the system, i.e. XML ->   ModelNodes
>>>> It would be great to be able to test the writing part as a unit too: ModelNodes ->   XML
>>>>
>>>> Cheers,
>>>>
>>>> David
>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Subsystem testing harness

kkhan
I moved the normalizeXml() method into AbstractSubsystemTest along with a few other small tweaks: https://github.com/jbossas/jboss-as/commit/0d3de0f834b0af7f7a0ca87e1c79c7aa50c491c1
On 25 Jul 2011, at 15:37, David Bosschaert wrote:

> Hi Kabir,
>
> It works for me. It allows for the following generic code to test
> read+write of any subsystem :)
>     String subsystemXML = "..."; // my subsystem XML
>     KernelServices services = installInController(new
> EmptyAdditionalInitialization() {
>         @Override
>         public Type getType() {
>             return Type.MANAGEMENT;
>         }
>     }, subsystemXml);
>     ModelNode model = services.readWholeModel();
>     String marshalled = outputModel(model);
>     Assert.assertEquals(normalizeXML(subsystemXml),
> normalizeXML(marshalled));
>
> Note that I used a normalizeXML method to treat the XML strings before
> using string compare to evaluate them. It takes into account things like
> normalizing attribute order, ignoring comments and pretty-printing
> elements to make sure that they are organized the same way. It might be
> an idea to add normalizeXML() to AbstractSubsystemTest. I've pasted it
> below.
>
> Cheers & thanks!
>
> David
>
> /**
>  * Normalize and pretty-print XML so that it can be compared using
> string compare.
>  * The following code does the following:
>  * - Removes comments
>  * - Makes sure attributes are ordered consistently
>  * - Trims every element
>  * - Pretty print the document
>  * @param xml The XML to be normalized
>  * @return The equivalent XML, but now normalized
>  */
> private String normalizeXML(String xml) throws Exception {
>     // Remove all white space adjoining tags ("trim all elements")
>     xml = xml.replaceAll("\\s*<", "<");
>     xml = xml.replaceAll(">\\s*", ">");
>
>     DOMImplementationRegistry registry =
> DOMImplementationRegistry.newInstance();
>     DOMImplementationLS domLS = (DOMImplementationLS)
> registry.getDOMImplementation("LS");
>     LSParser lsParser =
> domLS.createLSParser(DOMImplementationLS.MODE_SYNCHRONOUS, null);
>
>     LSInput input = domLS.createLSInput();
>     input.setStringData(xml);
>     Document document = lsParser.parse(input);
>
>     LSSerializer lsSerializer = domLS.createLSSerializer();
>     lsSerializer.getDomConfig().setParameter("comments", Boolean.FALSE);
>     lsSerializer.getDomConfig().setParameter("format-pretty-print",
> Boolean.TRUE);
>     return lsSerializer.writeToString(document);
> }
>
>
> On 21/07/2011 16:16, Kabir Khan wrote:
>> It has changed slightly after some comments from Brian and Emanuel. New commit is here: https://github.com/kabir/jboss-as/commit/e5144e1c6832756408f9385ed21b4df6abe49a33
>>
>> AdditionalInitialization.getType() == MANAGEMENT forces the non-install of services now
>> On 21 Jul 2011, at 16:43, David Bosschaert wrote:
>>
>>> Nice, thanks Kabir!
>>>
>>> I'll play around with that soon!
>>>
>>> David
>>>
>>> On 21/07/2011 15:37, Kabir Khan wrote:
>>>> My https://github.com/kabir/jboss-as/commits/parsing-harness contains some adjustements.
>>>>
>>>> https://github.com/kabir/jboss-as/commit/8f6538850604e0633c34c27d6fa70bb81dc180de#L6R108
>>>> shows how to invoke the ops without doing the RUNTIME part of the operation handlers, i.e. services will not get installed.
>>>>
>>>> https://github.com/kabir/jboss-as/commit/8f6538850604e0633c34c27d6fa70bb81dc180de#L6R186
>>>> shows how to just marshall a raw model to xml.
>>>>
>>>>
>>>> On 20 Jul 2011, at 16:40, David Bosschaert wrote:
>>>>
>>>>> On 20/07/2011 15:34, Kabir Khan wrote:
>>>>>> You need to start up MSC to get reference to the model controller since that is the only real way to get hold of the model controller. I guess you are saying you want the model changes and associated persistence of the xml to happen when invoking your ops, but not the installation of services?
>>>>> Yes, from a unit testing point of view that would be nice :)
>>>>>
>>>>> Currently I can test the reading part as a unit without causing any side effects in the system, i.e. XML ->   ModelNodes
>>>>> It would be great to be able to test the writing part as a unit too: ModelNodes ->   XML
>>>>>
>>>>> Cheers,
>>>>>
>>>>> David
>>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Subsystem testing harness

kkhan
When calling installInController() it now attempts to validate the operations against the subsystem description providers
On 1 Aug 2011, at 12:11, Kabir Khan wrote:

> I moved the normalizeXml() method into AbstractSubsystemTest along with a few other small tweaks: https://github.com/jbossas/jboss-as/commit/0d3de0f834b0af7f7a0ca87e1c79c7aa50c491c1
> On 25 Jul 2011, at 15:37, David Bosschaert wrote:
>
>> Hi Kabir,
>>
>> It works for me. It allows for the following generic code to test
>> read+write of any subsystem :)
>>    String subsystemXML = "..."; // my subsystem XML
>>    KernelServices services = installInController(new
>> EmptyAdditionalInitialization() {
>>        @Override
>>        public Type getType() {
>>            return Type.MANAGEMENT;
>>        }
>>    }, subsystemXml);
>>    ModelNode model = services.readWholeModel();
>>    String marshalled = outputModel(model);
>>    Assert.assertEquals(normalizeXML(subsystemXml),
>> normalizeXML(marshalled));
>>
>> Note that I used a normalizeXML method to treat the XML strings before
>> using string compare to evaluate them. It takes into account things like
>> normalizing attribute order, ignoring comments and pretty-printing
>> elements to make sure that they are organized the same way. It might be
>> an idea to add normalizeXML() to AbstractSubsystemTest. I've pasted it
>> below.
>>
>> Cheers & thanks!
>>
>> David
>>
>> /**
>> * Normalize and pretty-print XML so that it can be compared using
>> string compare.
>> * The following code does the following:
>> * - Removes comments
>> * - Makes sure attributes are ordered consistently
>> * - Trims every element
>> * - Pretty print the document
>> * @param xml The XML to be normalized
>> * @return The equivalent XML, but now normalized
>> */
>> private String normalizeXML(String xml) throws Exception {
>>    // Remove all white space adjoining tags ("trim all elements")
>>    xml = xml.replaceAll("\\s*<", "<");
>>    xml = xml.replaceAll(">\\s*", ">");
>>
>>    DOMImplementationRegistry registry =
>> DOMImplementationRegistry.newInstance();
>>    DOMImplementationLS domLS = (DOMImplementationLS)
>> registry.getDOMImplementation("LS");
>>    LSParser lsParser =
>> domLS.createLSParser(DOMImplementationLS.MODE_SYNCHRONOUS, null);
>>
>>    LSInput input = domLS.createLSInput();
>>    input.setStringData(xml);
>>    Document document = lsParser.parse(input);
>>
>>    LSSerializer lsSerializer = domLS.createLSSerializer();
>>    lsSerializer.getDomConfig().setParameter("comments", Boolean.FALSE);
>>    lsSerializer.getDomConfig().setParameter("format-pretty-print",
>> Boolean.TRUE);
>>    return lsSerializer.writeToString(document);
>> }
>>
>>
>> On 21/07/2011 16:16, Kabir Khan wrote:
>>> It has changed slightly after some comments from Brian and Emanuel. New commit is here: https://github.com/kabir/jboss-as/commit/e5144e1c6832756408f9385ed21b4df6abe49a33
>>>
>>> AdditionalInitialization.getType() == MANAGEMENT forces the non-install of services now
>>> On 21 Jul 2011, at 16:43, David Bosschaert wrote:
>>>
>>>> Nice, thanks Kabir!
>>>>
>>>> I'll play around with that soon!
>>>>
>>>> David
>>>>
>>>> On 21/07/2011 15:37, Kabir Khan wrote:
>>>>> My https://github.com/kabir/jboss-as/commits/parsing-harness contains some adjustements.
>>>>>
>>>>> https://github.com/kabir/jboss-as/commit/8f6538850604e0633c34c27d6fa70bb81dc180de#L6R108
>>>>> shows how to invoke the ops without doing the RUNTIME part of the operation handlers, i.e. services will not get installed.
>>>>>
>>>>> https://github.com/kabir/jboss-as/commit/8f6538850604e0633c34c27d6fa70bb81dc180de#L6R186
>>>>> shows how to just marshall a raw model to xml.
>>>>>
>>>>>
>>>>> On 20 Jul 2011, at 16:40, David Bosschaert wrote:
>>>>>
>>>>>> On 20/07/2011 15:34, Kabir Khan wrote:
>>>>>>> You need to start up MSC to get reference to the model controller since that is the only real way to get hold of the model controller. I guess you are saying you want the model changes and associated persistence of the xml to happen when invoking your ops, but not the installation of services?
>>>>>> Yes, from a unit testing point of view that would be nice :)
>>>>>>
>>>>>> Currently I can test the reading part as a unit without causing any side effects in the system, i.e. XML ->   ModelNodes
>>>>>> It would be great to be able to test the writing part as a unit too: ModelNodes ->   XML
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> David
>>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev