Argh, sorry, I built a CL on top of yours to illustrate and git cl upload overwrote yours on upload... feel free to run git cl upload again to get your CL back to where it was.
mTestRule.getTestFramework().startEngine();mCronetTestFramework
@Rule public final CronetTestRule mTestRule = CronetTestRule.withManualEngineStartup();Sebastian PorebaWhat this does is it makes every test run for every implementation in sequence.
But then you have tests that clearly only make sense to run once, such as `testLegacyUserAgent_whenOnPlatformSourceAndMetadataIsFalse`, which hardcodes the CronetSource and will therefore always run the same code for every implementation. Running it N times doesn't seem to make sense.
And then you have tests like `testLegacyUserAgent_whenNotOnPlatformSourceAndMetadataIsFalse`, which seem to reinvent CronetTestRule by iterating through every CronetSource in their own for loop. Which is already what CronetTestRule does, so you end up with N^2 effective test cases.
If this is intentional, please add code comments to explain the rationale, as this code makes me very confused.
If this is not intentional, either use CronetTestRule and `@IgnoreFor`, or use for loops, but please pick one. It would probably be simpler to use for loops, as you don't need most of the machinery CronetTestRule provides.
Etienne DechampsThis is intentional, you cannot modify context (= write the manifest flag) after the engine has started.
There is no "engine" that needs to be "started" here. You are testing UserAgent which does not interact with Cronet engines at all.
Please see https://crrev.com/c/7119519. Note this CL does pass tests.
@Rule public final CronetTestRule mTestRule = CronetTestRule.withManualEngineStartup();
public CronetTestFramework mCronetTestFramework;Sebastian PorebaI don't think you need this - it's overkill. I believe the following should work:
```
private Context getContextWithLegacyUserAgentOptIn(boolean value) {
Bundle metaData = new Bundle();
metaData.putBoolean(CronetManifest.USE_LEGACY_DEFAULT_USER_AGENT, value);
return (new CronetManifestInterceptor(metaData)).interceptContext(ApplicationProvider.getApplicationContext());
}UserAgent.from(getContextWithLegacyUserAgentOptIn(...), ...)
```
Etienne DechampsI think this comment got attached to the wrong line? If this is re setLegacyDefaultUserAgent - I moved it to the util, but the change you suggested won't work. CronetTestFramework needs to have the same context, so it needs to be passed down.
Sebastian PorebaThe comment is attached to the correct line.
The point I was trying to make is: you do not need CronetTestFramework *at all* in UserAgentTest.
```
public class UserAgentUtil {
public static ContextInterceptor getContextInterceptorWithLegacyUserAgent(
boolean value) {
Bundle metaData = new Bundle();
metaData.putBoolean(CronetManifest.USE_LEGACY_DEFAULT_USER_AGENT, value);
return new CronetManifestInterceptor(metaData);
}
}class UserAgentTest {
private Context getContextWithLegacyUserAgent(boolean value) {
return UserAgentUtil.getContextInterceptorWithLegacyUserAgent(value).interceptContext(ApplicationProvider.getApplicationContext());
}public void testLegacyUserAgent_whenOnPlatformSourceAndMetadataIsFalse() {
assertThat(UserAgent.from(getContextWithLegacyUserAgent(false),
class UserAgentIntegrationTest {
public void testDefaultUserAgent_legacyOptIn() throws Exception {
mCronetTestFramework.interceptContext(UserAgentUtil.getContextInterceptorWithLegacyUserAgent(true));
```Forget about CronetTestFramework. It brings in all kinds of code you don't need. The code under test (`UserAgent`) only needs a Context, it doesn't need all the engine-wrangling code.
Etienne DechampsI suspect this would suffer from the same problem as above - you cannot intercept the context so late. If you care I can try it and prove it, I'd rather not.
You don't need an engine in the first place.
You don't need any of this stuff.
The class that you are testing, UserAgent, is a completely self-contained class that does not interact with CronetEngine or the rest of Cronet at all. It can be tested without using any of the heavyweight test infrastructure like CronetTestRule, CronetTestFramework and the like. All this stuff is overkill.
Please see https://crrev.com/c/7119519. Note this CL does pass tests.
public class UserAgentUtil {Sebastian Poreba`org.chromium.net.impl.UserAgentUtil` looks like utils for production code. I would name this `userAgentTestUtil`.
Etienne DechampsIsn't that redundant in Java since tests are under a separate directory?
That's technically true, but when looking at the fully qualified name of the class (e.g. from references, or in a stack trace) this looks very much like some utils used by production code, it's not clear at all this is purely for tests.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
@Rule public final CronetTestRule mTestRule = CronetTestRule.withManualEngineStartup();Sebastian PorebaWhat this does is it makes every test run for every implementation in sequence.
But then you have tests that clearly only make sense to run once, such as `testLegacyUserAgent_whenOnPlatformSourceAndMetadataIsFalse`, which hardcodes the CronetSource and will therefore always run the same code for every implementation. Running it N times doesn't seem to make sense.
And then you have tests like `testLegacyUserAgent_whenNotOnPlatformSourceAndMetadataIsFalse`, which seem to reinvent CronetTestRule by iterating through every CronetSource in their own for loop. Which is already what CronetTestRule does, so you end up with N^2 effective test cases.
If this is intentional, please add code comments to explain the rationale, as this code makes me very confused.
If this is not intentional, either use CronetTestRule and `@IgnoreFor`, or use for loops, but please pick one. It would probably be simpler to use for loops, as you don't need most of the machinery CronetTestRule provides.
Etienne DechampsThis is intentional, you cannot modify context (= write the manifest flag) after the engine has started.
There is no "engine" that needs to be "started" here. You are testing UserAgent which does not interact with Cronet engines at all.
Please see https://crrev.com/c/7119519. Note this CL does pass tests.
As I mention in my other comment, in the end I'm fine with using CronetTestRule, but you still have the problem that using a for loop over sources (e.g. in `testLegacyUserAgent_whenNotOnPlatformSourceAndMetadataIsFalse`) *in addition to* CronetTestRule makes no sense to me.
If you get rid of these for loops, and keep CronetTestRule, I would be fine with that.
@Rule public final CronetTestRule mTestRule = CronetTestRule.withManualEngineStartup();
public CronetTestFramework mCronetTestFramework;That said, I realize now that CronetManifestTest (which is similarly disconnected from CronetEngines) does use CronetTestRule, and it does have the advantage of taking care of some subtleties like correctly intercepting Context#getApplicationContext.
So I'd be fine with the current approach as there is now a consistency argument that I was not aware of before.
mTestRule.getTestFramework().startEngine();Sebastian PorebamCronetTestFramework
Done
@Rule public final CronetTestRule mTestRule = CronetTestRule.withManualEngineStartup();Sebastian PorebaWhat this does is it makes every test run for every implementation in sequence.
But then you have tests that clearly only make sense to run once, such as `testLegacyUserAgent_whenOnPlatformSourceAndMetadataIsFalse`, which hardcodes the CronetSource and will therefore always run the same code for every implementation. Running it N times doesn't seem to make sense.
And then you have tests like `testLegacyUserAgent_whenNotOnPlatformSourceAndMetadataIsFalse`, which seem to reinvent CronetTestRule by iterating through every CronetSource in their own for loop. Which is already what CronetTestRule does, so you end up with N^2 effective test cases.
If this is intentional, please add code comments to explain the rationale, as this code makes me very confused.
If this is not intentional, either use CronetTestRule and `@IgnoreFor`, or use for loops, but please pick one. It would probably be simpler to use for loops, as you don't need most of the machinery CronetTestRule provides.
Etienne DechampsThis is intentional, you cannot modify context (= write the manifest flag) after the engine has started.
Etienne DechampsThere is no "engine" that needs to be "started" here. You are testing UserAgent which does not interact with Cronet engines at all.
Please see https://crrev.com/c/7119519. Note this CL does pass tests.
As I mention in my other comment, in the end I'm fine with using CronetTestRule, but you still have the problem that using a for loop over sources (e.g. in `testLegacyUserAgent_whenNotOnPlatformSourceAndMetadataIsFalse`) *in addition to* CronetTestRule makes no sense to me.
If you get rid of these for loops, and keep CronetTestRule, I would be fine with that.
Done
public class UserAgentUtil {Sebastian Poreba`org.chromium.net.impl.UserAgentUtil` looks like utils for production code. I would name this `userAgentTestUtil`.
Etienne DechampsIsn't that redundant in Java since tests are under a separate directory?
That's technically true, but when looking at the fully qualified name of the class (e.g. from references, or in a stack trace) this looks very much like some utils used by production code, it's not clear at all this is purely for tests.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
public class UserAgentTest {Can we add a test that ensures that HttpEngine's default userAgent is equal to the userAgent which we generate here? This is to ensure that HttpEngine's default userAgent does not accidentally change once this new code gets imported to stable.
The test could look something like `new HttpEngineNativeProvider(context).createBuilder().getDefaultUserAgent().equals(UserAgent.from(...)`.
It should ofcourse only run on Android U+.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
public class UserAgentTest {Can we add a test that ensures that HttpEngine's default userAgent is equal to the userAgent which we generate here? This is to ensure that HttpEngine's default userAgent does not accidentally change once this new code gets imported to stable.
The test could look something like `new HttpEngineNativeProvider(context).createBuilder().getDefaultUserAgent().equals(UserAgent.from(...)`.
It should ofcourse only run on Android U+.
I think `testDefaultUserAgent_noLegacyOptIn` already does this?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Commit-Queue | +2 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +2 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
| Commit-Queue | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Commit-Queue | +2 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Commit-Queue | +2 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |