Many tests are not tested with JavaCronetEngine |
|||||
Issue descriptionThere are many tests that are not annotated with @OnlyRunNativeCronet and are supposed to run both with the native Cronet and Java implementations. However, they are run twice with the Cronet implementation instead. The solution that is implemented inside CronetTestBase.java works only if CronetTestFramework is instantiated in the test SetUp() method. Instantiating CronetTestFramework directly inside the tests leads to double execution of the Cronet native implementation. CronetTestBase#runTest() is supposed to substitute the native Cronet implementation with Java implementation between the two test runs by assigning JavaCronetEngine implementation to CronetTestFramework.mCronetEngine field. This substitution does not work if a test is calling one of startCronetTestFrameworkXXX() methods. There are YY calls from tests that are not annotated with @OnlyRunNativeCronet: 17 calls to startCronetTestFramework() 5 calls to startCronetTestFrameworkWithUrlAndCronetEngineBuilder() 4 calls to startCronetTestFrameworkWithUrlAndCommandLineArgs() 12 calls to startCronetTestFrameworkAndSkipLibraryInit() 6 calls to startCronetTestFrameworkForLegacyApi()
,
Aug 16 2016
,
Oct 4 2016
,
Nov 28 2016
Related Issue 669264 . Having two test APKs can help in solving of this issue. The CronetTestBase class could be simplified. This would also guarantee that setUp() & tearDown() is called for every test.
,
Oct 17 2017
During the junit4 conversion I changed the way the native/java impls are tested. With junit4 the setUp() and tearDown() functions are called twice, but more relevant is that I made CronetTestCommon.startCronetTestFramework() decide whether to return a native or java impl depending on testingJavaImpl(), not defaulting to the native one like before.
,
Oct 17 2017
Since Paul fixed it, we can close the issue. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by xunji...@chromium.org
, Aug 16 2016