Add the reference tests for the request blocklist functionality

[catalinradoiu]

Task/Issue URL: https://app.asana.com/1/137249556945/project/1211724162604201/task/1211938369145726?focus=true

Description

Adds comprehensive reference tests for the Request Blocklist feature to validate blocking behavior against standardized test cases. The test suite covers basic blocking functionality, allowlisting interactions, tracker detection integration, incorrect rule handling, and rule ordering scenarios.

Steps to test this PR

Request Blocklist Reference Tests

• Run the new RequestBlocklistReferenceTest to verify all test cases pass
• CI pases

UI changes

No UI changes

---

Note

Low Risk
Test-only changes that add a new instrumented reference test suite and accompanying fixtures; no production logic is modified.

Overview
Adds a new Android instrumented, parameterized reference test (RequestBlocklistReferenceTest) that exercises WebViewRequestInterceptor request-blocklist decisions against the shared privacy reference test corpus.

Introduces new androidTest fixtures (tests.json, config-reference.json, tds-reference.json, surrogates-reference.txt, user-allowlist-reference.json) and updates copy-files-from-to.json to sync these files from @duckduckgo/privacy-reference-tests.

^{Written by Cursor Bugbot for commit 89face1. This will update automatically on new commits. Configure here.}

[catalinradoiu]

• Add the reference tests for the request blocklist functionality #7915 👈 (View in Graphite)
• Check if document url is in the exceptions list before blocking the request #7914
• develop

This stack of pull requests is managed by Graphite. Learn more about stacking.

[CrisBarreiro]

We shouldn't add these files manually to the repo, as reference tests are an external dependency that's versioned. Instead, we should bump the privacy-reference-tests dependency, and add the files to copy-from-to.json, so in case the contents of the files are updates, reference tests will always run on the latest version. See #5769 for reference

[CrisBarreiro]

This is testing WebViewRequestInterceptor, not RequestBlocklist, so I'd rename it

[catalinradoiu]

I followed the same approach as DomainsReferenceTest. In that case we are testing the WebViewRequestInterceptor as well, but the test is actually a reference test. I wanted it to be clear that this test file is for request blockist reference tests and not a regular unit test for WebViewRequestInterceptor.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: Missing else branch silently passes unknown actions
  • Added an else branch in the expectAction switch that calls fail(...) so unknown external action values now fail the test explicitly.

Or push these changes by commenting:

@cursor push 661262294e

Preview (661262294e)

diff --git a/app/src/androidTest/java/com/duckduckgo/app/referencetests/RequestBlocklistReferenceTest.kt b/app/src/androidTest/java/com/duckduckgo/app/referencetests/RequestBlocklistReferenceTest.kt
--- a/app/src/androidTest/java/com/duckduckgo/app/referencetests/RequestBlocklistReferenceTest.kt
+++ b/app/src/androidTest/java/com/duckduckgo/app/referencetests/RequestBlocklistReferenceTest.kt
@@ -87,6 +87,7 @@
 import org.json.JSONObject
 import org.junit.Assert.assertNotNull
 import org.junit.Assert.assertNull
+import org.junit.Assert.fail
 import org.junit.Before
 import org.junit.Rule
 import org.junit.Test
@@ -247,6 +248,7 @@
         when (testCase.expectAction) {
             "block" -> assertCancelledResponse(response)
             "allow" -> assertRequestCanContinueToLoad(response)
+            else -> fail("Unsupported expectAction '${testCase.expectAction}' in request-blocklist reference test '${testCase.name}'")
         }
     }

[cursor]

Missing else branch silently passes unknown actions

Low Severity

The when block handling testCase.expectAction only matches "block" and "allow" with no else branch. Since these are externally-versioned reference tests (from @duckduckgo/privacy-reference-tests), if the external package introduces a new action type (e.g., "redirect"), the test would complete without executing any assertion — silently passing as a no-op instead of failing. Adding an else branch that calls fail() with a descriptive message would prevent silent false-positive test results when the external test data evolves.

 

[catalinradoiu]

We are using the same pattern with the other tests. In this case we want to check only for block and allow actions, as we don’t have redirect.