geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Smith <>
Subject Re: [Discuss] Where should simple classes for tests belong?
Date Fri, 12 Oct 2018 22:41:37 GMT
What I think is important is that any java code should be in a Java source
file that is compiled as part of a build. Don't put java source or bytecode
in as resource or as a constant.

For testing deploy jar I thought what Helena and I ended up doing in
StartServerCommandDUnitTest worked pretty well - build a jar from a class
on the classpath:

File jar = temporaryFolder.newFile(jarName);
new ClassBuilder().writeJarFromClass(RunOutOfMemoryFunction.class, jar);


On Fri, Oct 12, 2018 at 3:32 PM Patrick Rhomberg <>

> Hello, all!
>   There are a number of classes that require some number of "toy" classes
> as part of their testing framework, e.g., to be used as custom data
> containers.  Many of these classes involve testing or use of the `deploy
> jar` command, and so are packaged into jars for this purpose.
>   In an effort to promote good coding habits and, as importantly, consensus
> throughout this community and our codebase, I would like to ask which of
> these are considered the preferred method to maintain these additional
> classes.
>   I realize a priori that none of these options will be applicable in all
> cases, but am curious of how the prioritization of these options are
> ordered among you all.
> -- Class definition --
> For definition of the classes consumed, we observe all of the following in
> the Geode codebase.
> Option C-1:  Toy classes are defined as a proper class in a reasonable
> package.
> -- suboption (a): The class is defined in the module in which it is
> consumed, as a resource.  [1]
> -- suboption (b): The class is defined in the module in which it is
> consumed, as a neighboring file.  [2]
> -- suboption (c): The class is defined in geode-dunit or geode-junit.  [3]
> Option C-2:  Toy classes are defined as inner classes of the test class.
> [4]
> Option C-3:  Sufficiently small toy classes are defined as raw String
> fields in the test class that consumed it and is compiled by the test JVM
> via the JavaCompiler class.  [5]
> -- Resource exposure --
> For those tests that require classes placed in Jars for use in the `deploy
> jar` command, we observe the following in the Geode codebase:
> Option J-1: Jars are a resource and are built or downloaded as necessary
> during the build steps, before test execution. [6]
> Option J-2:  Sufficiently small classes that are defined as raw String
> fields in the test class that consumes it (C-3 above) are packaged into
> resources via the JarBuilder class. [7]
> I look forward to hearing your opinions.
> Imagination is Change.
> ~Patrick Rhomberg
> Examples:
> [1]
> geode-core_test/
> is found by the FunctionScannerTest to be a user-defined function.
> [2]
> geode-core_distributedTest:org.apache.geode.internal.cache.SerializableMonth
> defines a simple DataSerializable containing an int for the month, to be
> consumed by *.MonthBasedPartitionResolver
> in PRCustomPartitioningDistributedTest.
> [3] geode-junit_main:org.apache.geode.cache.query.transaction.Person
> defines a simple DataSerilazable container class for a String name and int
> age.
> [4]
> is consumed by its parent class
> [5]
> defines a Customer class in a raw string in the test's @Before method.
> [6] See our own consumption of geode-dependencies.jar et al via the
>, or our historic consumption of tools.jar
> [7] See again [5] or other uses of the JarBuilder class.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message