| tag | b8d1978270ee78bba7bb6d0107fab53bbca32d41 | |
|---|---|---|
| tagger | The Android Open Source Project <initial-contribution@android.com> | Mon Aug 07 16:42:14 2017 -0700 |
| object | b03560c32573b9057dc1daaf877501dbb4e16f8d |
Android o preview 4
| commit | b03560c32573b9057dc1daaf877501dbb4e16f8d | [log] [tgz] |
|---|---|---|
| author | Paul Duffin <paulduffin@google.com> | Thu May 25 12:03:09 2017 +0100 |
| committer | Paul Duffin <paulduffin@google.com> | Fri May 26 18:09:41 2017 +0100 |
| tree | b4227f625f29e2426693f940545b2883b51fbe5d | |
| parent | 2a75dcb2fd1490ace0acf82e948aae2829b87e8d [diff] |
Fix JUnitParamsRunner so it works with CTS sharding CTS uses the Android Test Support Library's TestRequestBuilder.ShardingFilter to spread changes across a number of devices in order to parallelize testing. CTS runs the tests in two modes, in the first it collects the set of tests that will be run - the list of tests returned by Runner.getDescription() (after filtering) and in the second it actually runs the tests as returned by ParentRunner.getFilteredChildren(). JUnitParams does not work in that situation because it applies the filter in a different way for parameterized methods depending on whether it is collecting or running which leads to inconsistent methods in each phase which causes CTS problems. When collecting it creates a flat list of FrameworkMethod instances, one for each method, whether parameterized or not and applies the filter to that. Once it has filtered it iterates over to create the Description and during that process it creates N Description objects for each parameterized method and 1 Description object for each non-parameterized method. That means that for each parameterized method either every instance is collected or none of them are. When running it creates a flat list of FrameworkMethod instances, one for each non-parameterized method and N for each parameterized method (where N is the number of parameter sets supplied for the method). They are then filtered individually. That means that for each parameterized method some of its instances are run but not necessarily all. This fixes it by making the running and describing parts completely consistent in how they apply the filters. This change will be pushed upstream if possible. Tested by running the two commands given in the bug and ensuring that they produce the correct set of tests. Added target to build the test on host and ran selected tests from there. Ran all tests on the device as per instructions in Android.mk file. Bug: 38419944 Test: See above Change-Id: I25b4d4130ffdc71c77992abf592662ba1e1432db
Parameterised tests that don't suck
@RunWith(JUnitParamsRunner.class) public class PersonTest { @Test @Parameters({"17, false", "22, true" }) public void personIsAdult(int age, boolean valid) throws Exception { assertThat(new Person(age).isAdult(), is(valid)); } }
See more examples
JUnitParams project adds a new runner to JUnit and provides much easier and readable parametrised tests for JUnit >=4.6.
Main differences to standard JUnit Parametrised runner:
JUnitParams is available as Maven artifact:
<dependency> <groupId>pl.pragmatists</groupId> <artifactId>JUnitParams</artifactId> <version>1.0.4</version> <scope>test</scope> </dependency>
If you want to see just one simple test class with all main ways to use JUnitParams see here: https://github.com/Pragmatists/junitparams/tree/master/src/test/java/junitparams/usage
You can also have a look at Wiki:Quickstart
Note: We are currently moving the project from Google Code to Github. Some information may still be accessible only at https://code.google.com/p/junitparams/