geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Rhomberg <prhomb...@apache.org>
Subject [Discuss] Where should simple classes for tests belong?
Date Fri, 12 Oct 2018 22:32:45 GMT
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/resources:org.apache.geode.management.internal.deployment.ConcreteExtendsAbstractExtendsFunctionAdapter.java
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]
geode-core_distributedTest:java.org.apache.geode.internal.statistics.StatisticsDistributedTest$PubSubStats
is consumed by its parent class
[5]
geode-assembly_acceptanceTest:org.apache.geode.management.internal.cli.commands.PutCommandWithJsonTest
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
StartMemberUtils.java, or our historic consumption of tools.jar
[7] See again [5] or other uses of the JarBuilder class.

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