summaryrefslogtreecommitdiff
path: root/test-rules
Commit message (Collapse)AuthorAgeFilesLines
* API changes as requested by API council.Mathew Inwood2021-04-191-1/+0
| | | | | | | Bug: 183512729 Test: m Merged-In: I3c5a5734b4cf4f942c4f6809a0a54c2460ee2324 Change-Id: I3c5a5734b4cf4f942c4f6809a0a54c2460ee2324
* Inclusive Language Fixit: Replace dummy with fakePaul Duffin2020-07-282-27/+27
| | | | | | Bug: 162205877 Test: m java Change-Id: I294a033305448533d101349dc41bd216ce2ec63f
* Tweak SwitchTargetSdkVersionRule.Tobias Thierer2020-01-111-1/+1
| | | | | | | | | | | | | | | The state change that we reverse in the finally block should live before the try block, because if it throws then the finally block is also not needed. It shouldn't normally throw, so in practice this probably made no difference so far, but I'm fixing it because it sets a bad precedent (I've recently seen a draft CL that was inspired by this code and replicated this antipattern elsewhere). Test: Treehugger Change-Id: I20c679c6f934b1681ce40518c3b5215a1936fd5a
* CoreCompatChangeRule: Allow tests without change overrides.Tobias Thierer2019-11-251-3/+3
| | | | | | | | | | | | | A *Test.java file that uses @EnableCompatChanges or @DisableCompatChanges annotations on just one test case runs this rule on every test case. The rule was enforcing that all test cases must have such an annotation, but most *Test.java will apply annotations to only some of their test cases. Therefore, this CL drops the check for whether a test case carries at least one such annotation. Test: atest CtsLibcoreTestCases:libcore.junit.util.compat.CoreCompatChangeRuleTest Change-Id: I62331a99855d348aa8cc9272628f680eac333b53
* Revert "Revert submission from topic "separate-testing"."Andrei Onea2019-11-193-32/+153
| | | | | | | | | | | | This reverts commit d38b50d216334359b9969606cc611b8be217887f. The art buildbot was previously failing due to a transitive dependency on "api-stubs-docs" and "framework-res", via the unneeded "app-compat-annotations". This fix removes that dependency. Bug: 140367850 Test: atest CoreCompatChangeRuleTest Test: art/tools/buildbot-build.sh --host Change-Id: I34ca27ca5c56ebb23bbb858c287809bc93671427
* Use setOverridesFromTest in the test rule to avoid app kill.atrost2019-11-181-3/+4
| | | | | Test: https://r.android.com/1155184 Change-Id: Ib801c3df3cd0987309c2b5770c301b24261b3e73
* Revert submission from topic "separate-testing".Roland Levillain2019-11-153-153/+31
| | | | | | | | | | | | | Reason for revert: Breaks master-art builds with this error: FAILED: out/soong/.intermediates/development/build/android_stubs_current/android_common/turbine-combined/android_stubs_current.jar echo "module android_stubs_current missing dependencies: api-stubs-docs, framework-res" && false module android_stubs_current missing dependencies: api-stubs-docs, framework-res Test: art/tools/buildbot-build.sh --host Bug: 140367850 Exempt-From-Owner-Approval: Reverting change breaking ART builds Change-Id: I48f9505342cf035822b445df0fb8b2b778ef36d4
* Make (Core)CompatChangeRule libcore-specificAndrei Onea2019-11-143-31/+153
| | | | | | | | | | A separate implementation will be provided in Framework, to prevent cumbersome dependencies in libcore specific tests. Bug: 140367850 Test: atest CoreCompatChangeRuleTest Test: atest PlatformCompatGating Change-Id: Ieaf64174e016f946ec86c1521771af0a2a0ac3e5
* Revert submissionsatayev2019-11-073-202/+7
| | | | | | Reason for revert: breaks https://ci.chromium.org/p/art/builders/ci/angler-armv7-non-gen-cc/443 Change-Id: If849f0d15f121cfe44ba120c82a84c4bb8a5d324
* Make CompatChangeRule usable host-sideAndrei Onea2019-11-073-7/+202
| | | | | | | | | | | | CompatChangeRule can now be used host-side, which means that the system server specific api is ignored. This change also moves it to a different package, to avoid collision with android.compat.Compatibility. Bug: 140367850 Test: atest CompatChangeRuleTest Test: https://r.android.com/1158973 Change-Id: I661daf7dead3245f3b828355c8a2a0243776164a
* Remove redundant checks in CompatChangeRuleAndrei Onea2019-10-161-9/+4
| | | | | | | | | | Checking for overlap between enabled and disabled changes is redundant, as the check occurs already in the Compatibility.ChangeConfig constructor. Bug: 140367850 Test: http://aosp/1113771 Change-Id: I87526076a58bd33e733eb2bfff95d33822fffc87
* Add rule for toggling changes at test timeAndrei Onea2019-10-101-0/+147
| | | | | | | | Adds support for toggling gated changes at test time. Bug: 140367850 Test: http://aosp/1113771 Change-Id: I7980eb4d69d2f012b62731d93f43fa58d5ee7d54
* Add TestRule to enable access to deprecated BC algorithmsPaul Duffin2019-09-252-0/+127
| | | | | | | | | | | | | | | | | | | | | | | Android restricts access to a number of deprecated BouncyCastle algorithms to APKs that target SDK version <= 27. However, those algorithms still need testing. Rather than set the target SDK version to be <= 27 (which could have other side effects) tests use Providers.setMaximumAllowableApiLevelForBcDeprecation(int) to raise the level to make them accessible at the current target SDK version and resets it the default value afterwards. This change adds a JUnit test rule to implement that behavior and uses it to replace duplicate setUp() and tearDown() code across a number of tests. It also insulates the tests from having to access the internal sun.security.jca.Providers and dalvik.system.VMRuntime classes. This is intended to be used by external/conscrypt so that the conscrypt-tests module can stop depending on core-all-systems-module. Bug: 141539296 Test: atest CtsLibcoreTestCases Change-Id: If41b5c221c392e9b6d14d500537115d3380c4999
* Add JUnit 4 TestRule for running tests with a specific target SDKPaul Duffin2019-03-212-0/+213
| | | | | | | | | | | | | | | | | | | | | | | | Refactors code to replace lots of custom code for testing behavior for specific target SDK versions, whether it is try...finally... blocks or methods using lambdas with a JUnit 4 TestRule. As the tests were JUnit 3 that also required switching them from extending TestCase to extending TestCaseWithRules which adds support for JUnit 4 TestRules to TestCase. This is preparation work for some follow up work on ObjectStreamClass. Test: atest \ core-tests:org.apache.harmony.tests.java.io.ObjectStreamClassTest \ core-tests:libcore.java.lang.OldRuntimeTest \ core-tests:libcore.java.lang.PackageTest \ core-tests:libcore.java.lang.reflect.annotations.AnnotationsTest \ core-tests:libcore.java.util.CollectionsTest \ core-tests:org.apache.harmony.regex.tests.java.util.regex.PatternTest \ core-tests:libcore.junit.util.SwitchTargetSdkVersionRuleTest Bug: 109930347 Change-Id: I4ea11288eb344eaeb2e6cc9f3225748e518e1827
* Move libcore tests to non-libcore packages.Tobias Thierer2017-11-081-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Update to work with JUnit 4.12Paul Duffin2016-12-191-4/+4
| | | | | | Bug: 33613916 Test: make checkbuild Change-Id: Id85e23928c577515c436f6e6a21fa2afb00b1f83
* Improve documentation of ResourceLeakageDetectorPaul Duffin2016-11-071-22/+70
| | | | | | | | | 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
* Detect and fix resource leakages in testsPaul Duffin2016-10-211-3/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Improve resource leakage detection testingPaul Duffin2016-10-032-0/+262
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
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-20 03:13:28 +0000