| d430cc782689a7f6a256ef6b0ebfc7210b0c31d9 |
|
01-Nov-2017 |
Tobias Thierer <tobiast@google.com> |
Move libcore tests to non-libcore packages.
The integration of OpenJDK 9 javac into the Android build system
requires non-libcore code to live in non-libcore packages, as
long as that code isn't considered part of the same module as
libcore at javac time.
This CL moves libcore test related classes out of such
packages; since libcore tests could already only test
public (as opposed to package private APIs), no change
other than the package name and imports is necessary.
Because many libcore tests already live below a top-level
package "libcore" (eg., the tests for java.util are in
libcore.java.util), this CL likewise prepends "libcore."
to the package names of affected classes. For classes
relating to libcore.* packages, this results in a package
name of the form "libcore.libcore.*".
Alternative considered but not pursued:
To compile the test classes without moving the out of a libcore
package, javac would need to consider them to be in the same
module as libcore. This would likely be possible via
javac --patch-module, but this has not been explored in detail
because:
- Most luni tests are already in a toplevel package libcore.*,
so this CL makes the test structure more consistent.
- Use of --patch-module would likely cause problems when running
tests under a runtime that implements the OpenJDK 9 module
system; for example, --patch-module cannot add exported
packages to the module, so any new packages added in tests
(such as the libcore.* packages of most existing luni tests)
would not be visible at test runtime.
- Having tests in different packages from code under tests makes
it more obvious (including to IDEs in which the code might be
edited as a single project) that these tests cannot access
package-private identifiers in the code under test.
Test: Treehugger
Test: "make cts" with EXPERIMENTAL_USE_OPENJDK9=true
passes with additional changes present locally
that have not yet been exported as CLs.
Test: CtsLibcoreTestCases
Bug: 68224249
Bug: 68932217 (tracks potential follow-up work)
Change-Id: Ib6b8e6f3bc87093bc219d2108e601163c6e334cd
|
| 88df7911980a895f9379d9a0e4cbf46aaadf90d0 |
|
28-Oct-2016 |
Paul Duffin <paulduffin@google.com> |
Improve documentation of ResourceLeakageDetector
Adds examples and adds a check to provide better feedback if it
is used incorrectly.
Test: Ran CTS tests and vogar tests
Bug: 31542223
Change-Id: Ibd45de91e3ee024294a1ee10e22c67039735a461
|
| 27604018f783bf6354a13870b3e7785edca69b5f |
|
28-Sep-2016 |
Paul Duffin <paulduffin@google.com> |
Detect and fix resource leakages in tests
Tests that test those classes that use CloseGuard to detect
reosurce leakages are switched to use TestCaseWithRules and
ResourceLeakageDetector.getRule() to detect any resource
leakages and the leaks fixed.
A number of tests could not be fixed due to bugs in the core
classes so a new DisableResourceLeakageDetection annotation was
added as part of this change. A method annotated with that does
not perform resource leakage detection. The affected tests were
annotated with a description and a reference to an associated
bug.
This uses try-with-resources to aid in closing resources. While
that does provide some benefits it is all too easy to change the
behavior of the test unless care is taken. To avoid that it is
important not to merge it with an existing try block such as
those which follow the following pattern:
try {... fail()} catch(..) {}
Merging them could result in the test catching and ignoring
exceptions thrown during the creation of the resource which is
almost certainly not what the test was intending.
Test: Tested with vogar and CTS
Bug: 31542223
Change-Id: Id32bb40fe04eb9719d7e6cd367abb53118b21832
|
| fe0ee8ef8870338ad67ebfb6b62785e0cbdb325b |
|
12-Aug-2016 |
Paul Duffin <paulduffin@google.com> |
Improve resource leakage detection testing
This change makes various improvements to the support for
testing resource leakage detection.
Adds CloseGuard.Tracker to allow tests to track the lifecycle of
CloseGuard allocation sites directly.
Adds CloseGuardSupport to use CloseGuard.Tracker to provide:
* A BiConsumer that can be used to help check that objects which
own resources protected by CloseGuard correctly detect resource
leakage.
* A TestRule that allows tests to check that system code does
not leak resources, especially under error conditions.
Adds a new ResourceLeakageDetector that uses reflection to
access CloseGuardSupport. This can safely be used in code that
needs to compile and run on OpenJDK.
Adds TestCaseWithRules to allow the TestRule above to be used
with JUnit 3 style tests without converting the whole test to
JUnit 4 style.
Changed libcore.java.lang.ProcessBuilderTest to use TestCase as
ProcessBuilder does not have any CloseGuard protected resources.
That allows AbstractResourceLeakageDetectorTestCase to be
deleted.
Changed RandomAccessFileTest to use TestCaseWithRules and
ResourceLeakageDetector. Fixed issues that it highlighted,
fixed testRandomAccessFileHasCleanupFinalizer test and removed
it from expectations/knownfailures.txt.
Adds core-test-rules/-hostdex targets to encapsulate TestRule
and related classes that can be shared with other projects.
Removes the following now unused classes:
* CloseGuardMonitor
* AbstractResourceLeakageDetectorTest
* The old ResourceLeakageDetector and associated test.
Bug: 31542223
Test: Ran tests on both Vogar and CTS
Change-Id: I8f802b52fdbeac0a30f339a9ceca5d2eaaafd180
|