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
