feat: comprehensive integration test suite with 737 tests

[AniketDev7]

Complete rewrite of integration testing infrastructure with focus on coverage, maintainability, and security.

TEST INFRASTRUCTURE:

• Created TestDataHelper for centralized configuration management
• Created AssertionHelper for robust, reusable test assertions
• All configuration loaded from environment variables
• Zero hardcoded credentials or stack-specific data
• Feature-based folder structure for better organization

TEST COVERAGE (737 tests across 37 test suites):

• Core SDK: Query operators, entry fetching, field projection
• References: Single/multi-level resolution, circular references
• Global Fields: Structure validation, nested data, references
• Metadata: Schema inclusion, content type metadata
• Localization: Multi-locale support, fallback behavior
• Variants: Content variant queries and validation
• Taxonomies: Hierarchical taxonomy filtering
• Assets: Query operations, image transformations
• Cache Policies: All 5 cache strategies tested
• Sync API: Initial sync, delta updates, pagination
• Live Preview: Management/preview token support
• Branch Operations: Branch-specific content fetching
• Plugin System: Request/response hook validation
• Network Resilience: Retry logic, concurrent requests
• Region Configuration: Multi-region API support
• Performance: Benchmarks and stress testing
• Real-World Scenarios: Pagination, lazy loading, batch operations
• JSON RTE: Rich text parsing, embedded content
• Modular Blocks: Complex nested structures
• SDK Utilities: Version info, utility methods
• Error Handling: Graceful degradation, edge cases

This test suite provides comprehensive coverage of the SDK while maintaining portability and security for public repository use.

The best way to fix the problem is to prevent logging the cleartext value of branchUID, especially as it sources from an environment variable.
To maintain some information for debugging while not leaking possibly sensitive data, either:

• Omit the log entirely, since branch identification can usually be reconstructed from context, or
• Replace the exact value with a redacted/masked form (such as a generic notice: "Branch configured" or "Branch configured: [MASKED]"), or
• Log only for non-sensitive defaults (e.g., only for "main"), or
• If logging is necessary for all cases, mask the value except perhaps the first/last character or show a fixed message.

Given that the safest fix is to avoid leaking at all, the single best approach is to remove (comment out or delete) the log statement at line 132:

console.log(`ℹ️  Branch configured: ${branchUID}`);

Alternatively, if you want to maintain the log, replace the branch value with "[REDACTED]" or similar.

Required changes:

• Edit test/integration/AdvancedTests/CustomParameters.test.js, remove or replace line 132 (console.log(...)) only.
• No imports, methods, or variable definitions are needed.

---

The fix should prevent the logging of unredacted environment-derived information, specifically the branch UID value, in test logs. Rather than outputting the actual branch UID (which could be sensitive in some contexts), the log statement should confirm the expected behavior without revealing the value. Replace the template string with a fixed message such as "✅ Branch header added" (omitting the value), or, if helpful, with a generic marker confirming presence without revealing contents. Only the log statement at line 53 in test/integration/BranchTests/BranchOperations.test.js needs changing; no further imports or helpers are required.

---

To fix the issue, ensure that any test log messages do not output environment-derived values that could be sensitive, such as values sourced from process.env (even if they are UIDs). In practice, the log message on line 91 should either omit the entryUID value or redact it so that only non-sensitive context (e.g., the presence of an error code) is logged. This can be achieved by explicitly removing or masking the variable in the log output. Only the necessary context for debugging should be retained.

The required change is in test/integration/ModularBlocksTests/ModularBlocksHandling.test.js on line 91. Change the message so it does not show the value of entryUID (and, optionally, also mask the error code if it might be sensitive). No additional imports or methods are needed; just edit the log statement to not display sensitive information.

---

To fix the problem, avoid logging the raw value of entryUID (or any value derived from environment variables/configuration that might be sensitive). Instead, redact the value, mask it, or rather refer to its presence/absence without displaying the concrete data. The error message should still provide enough debug value to understand the failure. We can indicate that an entry was not found for the configured "self-referencing entry UID" without specifying the actual UID in the log output. Only line 200 needs to be changed; no imports/methods are needed.

---

To fix this issue, we must avoid logging the value of variantUID directly, as it is derived from the environment. Instead, the log line should report the result of the variant query without echoing the actual UID value. This means removing or masking the ${variantUID} interpolation in the log message while retaining useful context. Change only the log message on line 60 in test/integration/VariantTests/VariantQuery.test.js, ensuring not to leak the environment-derived variable's value. No other code changes or imports are required.

---

The best way to fix the problem is to avoid logging the potentially sensitive environment-derived value (variantUID) in clear text. Instead, log only non-sensitive status information (e.g., that no entries were found), and omit or mask the value. For maximum safety and future-proofing, the message should not include variantUID at all.
The edit is to update line 67 in test/integration/VariantTests/VariantQuery.test.js to remove the direct logging of the variantUID.
No imports or method changes are needed: just update/remediate the log statement.

---

The best way to fix this issue is to avoid logging the actual value of the variantUID, which comes from an environment variable. Instead, log only static test success/failure messages that do not include potentially sensitive data. In file test/integration/VariantTests/VariantQuery.test.js, line 313 should be changed to a message like "✅ Entry.variants(): entry fetched", omitting the interpolation of variantUID. No imports or additional definitions are necessary.