ok, thanks for explanation. On 4/16/08, Regis <[EMAIL PROTECTED]> wrote: > Ideally, I could use "real" schema data for testing, as we saw, the data is > big, > 80k+ in serialized form, I can't image how many hashmap.set() would be used. > IMHO, if we used mock data, hashmap.set() is the best choice. Maybe using > text data is best the choice for me now. > > Best Regards, > Regis. > > > Tony Wu wrote: > > What we need actually is some hashmaps. why we can not create it in > > java src code such as setUp method through several/a lot hashmap.set() > > . What's your concern on this manner? > > > > On 4/16/08, Regis <[EMAIL PROTECTED]> wrote: > > > > > I agree that the large binary file is hard to modify and maitain, maybe > we > > > have another choice to > > > construct the schemaTable, using raw text data returned from server. We > need > > > parse the raw text > > > data first, and then construct the hashmap. The data is in text format, > so > > > it's easy understand and modify. > > > > > > What i concerned about this way is for unit test it seems a bit complex > and > > > involve process of > > > parsing schema which should be tested separately. > > > > > > Best Regards, > > > Regis. > > > > > > > > > Tim Ellison wrote: > > > > > > > Regis Xu (JIRA) wrote: > > > > > > > > > > > > > Let me explain. > > > > > > > > > > The file contains necessary data to construct LdapSchemaContextImpl > > > > > > > > > > > > instance for testing. > > > > > > > > > > > > LdapSchemaContextImpl is constructed using schema data queried from > LDAP > > > > > > > > > > > > server, then > > > > > > > > > > > > it cached all scehma data in "schemaTable", it's fast for searching. > > > > > It's best if we could test LdapSchemaContextImpl with "real data" > > > > > > > > > > > > returned from LDAP server. So we serialize the "real" schemaTable to the > > > file and deserialize it when testing, then we got a "real" > > > LdapSchemaContextImpl without connecting with server. > > > > > > > > > > > > for 1) we can construct the table from java code but the schema > data is > > > > > > > > > > > > too large, i think it's not reasonable > > > > > > > > > > > > to put it in java file. > > > > > > > > > > Maybe we could remove .ser from file name, which cause confusion > with > > > > > > > > > > > > testing serialization capabilities. > > > > > > > > > > > > I hope i had myself explained clearly. > > > > > > > > > > > > > > Yes, it is a clear explanation Regis, but I have a concern that this > > > > > > > serialized file is a large binary blob that is hard for people to modify > if > > > they choose to change the tests. > > > > > > > I realize that we don't want to require an LDAP server to test > against, > > > > > > > and your idea for capturing the "real data" as a serialized data object > > > makes sense. But, what if there is a bug or enhancement that somebody > else > > > needs to make, and they don't have your LDAP server available to > re-create > > > the "real data"? I think it will be a maintenance problem. > > > > > > > Maybe I'm being too unreasonable, and right now I can't think of a > > > > > > > different way to do it (other than write the Java source code to create > the > > > "real data" hashmap of hashmaps I saw when I deserialized the blob). > > > > > > > Regards, > > > > Tim > > > > > > > > > > > > > > > > > > > > > >
-- Tony Wu China Software Development Lab, IBM
