Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Project Preference Store

I've been looking recently at creating unit test cases related to serialization. Something pretty basic like serialize a project description to a storage (preferable to a local string), then load to another project description and compare. Have similar unit test cases for subcomponents of ICProjectDescription. Turns out to be not a trivial task. For one thing, serialize API does not look suited to be used for unit testing. Can anybody tell how to serialize to a string or to at least to a different file and read from there? Serialize methods in subcomponents of ICProjectDescription are private and not easy to get hold on. Can we standardize serialize API for every component of project description being serialized and expose it as public methods? I suppose this way is correct:

public void serialize(ICStorageElement element);
public static CSerializedClass load(ICStorageElement element);

Another problem is how to compare two project descriptions (or their components). The problem is in sheer number of parts involved. It breaks to 50 or more classes, most of them not being serialized but probably should be checked anyway. I've been doing some of that this way, it is doable:


public class AssertIConfiguration {
static public void assertEquals(String message, IConfiguration expected, IConfiguration actual) {
if (expected == actual) return;

if (expected != null && actual != null) {
AssertIBuildObject.assertEquals(message, expected, actual);
AssertIBuildObjectPropertiesContainer.assertEquals(message, expected, actual);

Assert.assertEquals(message, expected.getArtifactExtension(), actual.getArtifactExtension());
Assert.assertEquals(message, expected.getArtifactName(), actual.getArtifactName());
                        ....
                        AssertIBuilder.assertEquals(message, expected.getBuilder(), actual.getBuilder()); 
                        ...
return;
}
junit.framework.Assert.failNotEquals(message, expected, actual);
         }
}


I think that kind of unit testing would be helpful to ensure that serialization is not being broken while being cleaning up.

Andrew

On Tue, Oct 21, 2008 at 8:27 AM, Schaefer, Doug <Doug.Schaefer@xxxxxxxxxxxxx> wrote:
Yes, there are many ways of doing trees in a property set. You could use
qualifiers or paths in keys as well.

I guess my hope was that it would be good enough to get out of the
setting store business. The less time we spend on figuring out how to
store build settings, the more we can spend on cleaning up some of the
more serious issues we have, like redoing scanner discovery.

Doug.

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of James Blackburn
> Sent: Tuesday, October 21, 2008 4:17 AM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Project Preference Store
>
> > There are a couple of issues I can forsee with this:
> > - How do you handle ICSettingsStorage ICStoargeElement trees ?
> >  Currently everything is stored in a tree. Key / Value preferences
> > aren't really a suitable replacement (and I think storing
> xml trees in
> > values will make version control even harder...)
>
> Taking a look at IEclipsePreferences more closely, they can
> represent a tree like store.. So that objection goes out the
> window :)...
>
> My aim with my current work is to allow any tree based
> storage to be used for persisting the model -- so something
> like this would plug-in nicely with (hopefully) little effort.
>
> James
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top