This change adds a backtrace() method which returns a list of events
that were received since the last time a user called poll() on a
ReadHead. This is particularly useful for logging observed events while
a poll was in progress that did not end up matching an event.
Test: atest EthernetManagerTest
Change-Id: If019cf9eb5e3e9268c5e6b74edbd8f49959cc71c
This will typically be used in mainline-presubmit TEST_MAPPING
configuration to exclude some tests.
This is necessary as some tests are flaky in mainline configurations
(when running on older devices), and they need to be disabled to meet
SLO requirements, but they are not flaky on presubmit using the latest
platform builds.
Test: m
Change-Id: Ia532d6d3f9833ddec613d79c0eb517d20a1c529a
This annotation can be used to mark a test case that requires
the latest resolv module. Tests that don't run with the latest
resolv module (for example CtsNetTestCasesLatestSdk) can exclude
the testcases being flaky due to some known issues in old resolv
module.
Bug: 279846955
Test: TreeHugger
Change-Id: Ie19eed1c4aa17645c4eec45493e7999027a01205
This annotation can be used to exclude the testcases which requires the
latest NetworkStack module in the CTS/MTS suite.
Bug: 283200648
Test: atest CtsTetheringTestLatestSdk
Change-Id: Idaffed93af077c2998081142af7b3bfa311dcd90
...and rename ExceptionUtils to FunctionalUtils as the old name
would no longer be appropriate.
Test: FrameworksNetTests
Change-Id: I2affd69fb84d7f250b4a45497eec6c052bf6ec50
Throwable could be used as a type argument to catch(), but it would
possibly never be caught, because the method only catches Exception.
Notably, junit assertions fail with AssertionError, which is not a
subclass of Exception. Due to that, tests or utilities like
DeviceConfigRule that have failing assertions in catch() would not
run the subsequent cleanup steps.
Bug: 210377950
Test: atest CleanupTest
Change-Id: I54e2922cb466f077ba4d219f8c3c6f885316296c
This is useful for some tests that need to make sure a few
things all happen, but some of them may throw an exception.
In vanilla Java you'd say
try {
...
} finally {
try {
...
} finally {
try {
...
} finally {
...
}
}
}
With this patch, you can pass a list of blocks to clean.
Kotlin :
tryTest {
...
} cleanupStep {
...
} cleanupStep {
...
} cleanup {
...
}
Java :
tryAndCleanup(() -> {
...
}, () -> {
...
}, () -> {
...
})
This keeps the semantics of tryTest{} of throwing any
exception that was thrown in tryTest{} and adding the
exception in the cleanup steps as suppressed.
Test: new tests for this
Change-Id: Ie26b802cb4893e13a70646aa0b7887701dee1ec6
This is the same thing try{} does, and allows to lift
return out of tryTest.
This allows syntaxes like :
fun foo() = try {
"Foo";
} cleanup {
doSomeCleanup()
}
}
val network = try {
registerNetworkCallback
callback.getNetwork()
} cleanup {
unregisterNetworkCallback
}
}
Note: bypassing ktlint because of b/185077240
Test: FrameworksNetTests
Change-Id: Ib8f6fde7ccfd62fdcb3c1e3b7b03909ed94d4b23
Non-local returns will prevent the execution of the cleanup{}
block, which is too much of a footgun to allow. See the bug
for details of how it happens.
There doesn't seem to be a way to keep the nice syntax, allow
non-local returns and still guarantee execution of the cleanup
block in all cases. Thus, forbid non-local returns. Users can
still use return@tryTest to accomplish almost the same thing,
and the next patch will also let tryTest{} return its last
evaluated value, fixing remaining cases.
E.g.
tryTest {
foo()
if (condition) return result
bar()
} cleanup {
doCleanup()
}
can always be written
return tryTest {
foo()
if (condition) return@tryTest result
bar()
} cleanup {
doCleanup()
}
...and it's a rare case, so the additional syntax is acceptable.
Test: NetworkStaticLibTests
Bug: 207358921
Change-Id: I40443acf7e4d86813641adc877e27fb2334d0daf
In fact the test already passes, because addSuppressed contains
an explicit test that if this === argument, then it doesn't add
it. But otherwise that's a bug in tryCleanup
Test: NetworkStaticLibTests
Change-Id: I202790bbe8d82445c5affdd9076561c2c6ea9b59
A common pattern in tests is to use try-finally to make sure
cleanup is executed. This is necessary in CTS in particular to
make sure the test does not leave the device in a bad state.
The problem with using try-finally in this manner is that any
exception thrown in the finally{} block will override any thrown
in the try{} block. If the exception in finally{} is caused by
the one from try{}, then the stack trace reported by the tools
is the consequence and not the cause, making it difficult to
interpret the stack trace of automated tests.
So today, code has to make sure that either the code in
finally{} can't throw, or can't be affected by any code in
try{}, and both of these are really difficult to ensure in
presence in finally{} of code the tester does not control.
What we'd want ideally is a structure like try-finally, that
guaratees the code in finally{} is executed in all cases,
but that bubbles up the exception from try{} if any, and
will still bubble up any exception from finally{} if the
try{} block hasn't thrown.
That's what this new tool does.
Usage from Kotlin is like try-finally :
tryTest {
testing code
} cleanup {
cleanup code
}
Usage from Java can't be made as nice, but it's relatively okay :
testAndCleanup(() -> {
testing code
}, () -> {
cleanup code
});
Bugs listed below are some tests that have been affected by
this issue and have unhelpful traces.
Test: new test for this code
Bug: 198586720
Bug: 198998862
Change-Id: I54b30a7d53772feeade99274b6120a79707ad1c9
The annotation will be used to mark tests cases that are part of MTS
modules used by multiple modules, to indicate that the test case should
only be run if the MTS suite should cover an updated Connectivity
(tethering) module.
This allows tests to verify new behavior in the Connectivity module,
without failing if that module is not updated.
Bug: 196755836
Test: mts-tradefed run mts-network with exclude-annotation in the config
Change-Id: I05d2200c7ab68042e4e48029e045f164c26b8037
Having the test targets in a different directory allows setting
visibility rules for tests only, which is necessary for access to
targets that should not be used for device builds.
Bug: 182859030
Test: m
Change-Id: Iaf426cf339a97833acf80c941db692329c6e2dcb
