Stepan Mishura wrote:
Hi George,
I like you idea with loading test's resource files. I don't see any
maintenance issues with putting all resource files into "src/test/resources"
folder, for example, if a test have several resource files then I'd like to
keep them in separate folder rather then in a test's folder. Also don't
think that there will be name collision problems: java files go to
"test/java" and resource files go to "test/resources". Is anybody going to
put class files there?
As long as you keep a parallel package tree, it should be equivalent of
how we do it now. Not quite sure what we gain other than it's neater...
geir
George Harley wrote:
2) The need for the "TEST_SRC_DIR" system property goes away if method
getDataFile() were updated to use java.net.URI.
e.g,
protected File getDataFile(int index) {
String name = "/" + this.getClass().getName().replace('.', '/') + "."
+ index + ".dat";
return new
File(URI.create(this.getClass().getResource(name).toString()));
FYI, SerializationTest.java is not the only one case. There are few places
where "TEST_SRC_DIR" system property is used, for example, policy resource
files see:
modules/security/test/common/unit/javax/security/auth/PolicyTest.java
modules/security/test/common/unit/javax/security/auth/jaas_policy1.txt
modules/security/test/common/unit/javax/security/auth/jaas_policy2.txt
I think it won't be an issue to fix them if your suggestion will be
accepted.
BTW, as far as I remember we agreed to call new security module 'auth'
because of 'JAAS' trademark issues so I guess we should rename two policy
files say to auth_policy<n>.txt. I'm going to search all such cases and
provide a patch.
Thanks,
Stepan Mishura
Intel Middleware Products Division
On 3/11/06, George Harley wrote:
Hi Mikhail (again),
Just a couple of brief observations about the SerializationTest.java
code as it stands in SVN today :
1) The reference/golden .dat files for Serializable classes in a given
module could be added under the module's src/test/resources directory
(in sub-folders corresponding to their package names). In an Ant build
these would be copied under the test bin using a tweaked version of the
"copy-test-resources" target (see the proposed changes to
make/build-java.xml contained in the HARMONY-57). At runtime this would
make the .dat files available from the classpath.
2) The need for the "TEST_SRC_DIR" system property goes away if method
getDataFile() were updated to use java.net.URI.
e.g,
protected File getDataFile(int index) {
String name = "/" + this.getClass().getName().replace('.', '/') + "."
+ index + ".dat";
return new
File(URI.create(this.getClass().getResource(name).toString()));
It seems to me that the src/test/resources directory would be an ideal
place to keep a module's reference .dat files.
Best regards,
George
George Harley wrote:
Mikhail Loenko wrote:
2006/3/9, George Harley <[EMAIL PROTECTED]>:
...
Such a testing effort still sounds pretty daunting though.
BTW, there is a framework for serialization testing which is currently
in the security module:
modules/security/test/common/unit/org/apache/harmony/security/test/SerializationTest.java
It serves to simplify serialization testing and has the docs inside.
Actually
almost all serializable security-related classes are tested with this
framework.
Does it make sense to move the framework to a common place?
Hi Mikhail !
I've spent a little bit of time running this (with a couple of my own
little concrete subclasses of SerializationTest) and I really like it.
It was pretty straightforward to create a JUnit error for the case of
java.util.TimeZone after my overridden version of getData() used
TimeZone.getDefault() to generate a couple of TimeZone instances from
the RI.
I can definitely see a case for broadening this approach outside just
the security classes. Really impressive stuff !
Best regards,
George
Thanks,
Mikhail
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
