On Fri, Jan 18, 2019 at 5:49 PM Robert Varga <[email protected]> wrote: > On 18/01/2019 23:35, Sam Hague wrote: > > > > > > On Fri, Jan 18, 2019 at 5:24 PM Tom Pantelis <[email protected] > > <mailto:[email protected]>> wrote: > > > > > > > > On Fri, Jan 18, 2019 at 4:13 PM Sam Hague <[email protected] > > <mailto:[email protected]>> wrote: > > > > Any idea if there is a portable java method that can take json > > as input and output java objects? Or some example code that > > maybe isn't as generic, but with some case-specific coding could > > do the same? > > > > The use case is for writing unit tests. Every new listener I add > > tests for I always create helper methods to fill out the java > > objects, write to mdsal, do some verifications, write some more > > and so on. It would be much more readable to simply input a json > > into this new helper method and out pop a java object that can > > be written to mdsal. > > > > I imagine the restconf project has something similar since it > > parses incoming json. Or maybe it is using some libraries to do > > the same? > > [...] > > > Nice, Ok this looks like a good way to do it. I could extract that piece > > of code and feed it the models I know need to be converted. And that > > should be pretty lightweight for that piece of code, right? Doesn't look > > like there are many dependencies just for that part. > > Assuming you get through the black magic of setting up > BindingRuntimeContext and SchemaContext -- but you can get all of that > from AbstractDataBrokerTest. > When you say get from the Abstract, do you mean if I add that in it will be there - or do you mean it is already there and I just need to expose it?
> > Can you file an improvement to extend AbstractDataBrokerTest with that > sort of capability, please? > > I know JSON is the rage these days, but genius went a different route, > using a combination of normal builders and Xtend. The result looks very > reasonable: > Yes, NetVirt started this with Michael and moved to Genius with his lead. > > > https://github.com/opendaylight/genius/blob/master/itm/itm-impl/src/test/java/org/opendaylight/genius/itm/tests/xtend/ExpectedDeviceVtepsObjects.xtend > > For bonus points: > > 1) it is part of compilation, hence you get rather immediate feedback > when you mess up, rather than dealing with parsing exceptions > How is this much different than creating helper builders? Unless it is easier. But the goal with json is because we always use json to test via the restconf and it is readable, so that had great value in the tests. You were already going to make the json, so reuse that to feed the test and then you focus on the test. I admit I didn't see the xtend that much easier than builders. It also seems xtend related stuff keeps breaking or requiring parent bumps to fix, which makes it difficult to rely on the tests. > > 2) you can reuse them just as you would with normal constants > > 3) cross-reference navigation works (with an eclipse plugin) > Intellij... > > Regards, > Robert > >
_______________________________________________ Discuss mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/discuss
