Task description

• Document how-to override datastream config
• FAQ/Cookbook for usecases to use datastream config override
• Update github doc (api-ref)

Additional implementation details or code snippet(s)

No response

Task description

For the test NetworkService update the workflow for integration testing, similar to the iOS implementation:

• the setup step overwrites the network service; functional vs integration tests make the corresponding setup
• each test can set expected requests, and assert on network requests sent out, response connections
• reuse existing helpers for functional tests (FunctionalTestNetworkService)

Additional implementation details or code snippet(s)

No response

Task description

Currently the "eventIndex" for event errors and event warnings in the interact response is expected to be a top-level field in an event error/warning object. However, Konductor defines the eventIndex in the "report" object, so Edge is looking in the wrong place for that field.

• Change NetworkResponseHandler to look for "eventIndex" in the "report" object of the event error and event warning objects.
• Update test cases accordingly.

Additional implementation details or code snippet(s)

No response

Task description

For the assertions on event payloads, we need the ability to check the logical equivalence of JSON dictionaries, similar to the iOS framework capabilities:

• key presence
• value type and value matching
• array ordered/unordered matching

Reuse existing tools where available in Core or current test framework.

Additional implementation details or code snippet(s)

No response

Epic description

Scope:

• Add the new AEPTestUtils framework as a test dependency to Edge extensions
• Remove duplicated classes that are now supported by AEPTestUtils
• Adopt the common Mock/RealNetworkService from AEPTestUtils
• Adopt the new JSONAssert system for JSONs and dictionary comparisons

This applies for all existing tests for Edge extensions: unit, functional, integration.

Tasks

• Edge #127
• Consent adobe/aepsdk-edgeconsent-android#74
• Edge Identity adobe/aepsdk-edgeidentity-android#115
• Edge Media adobe/aepsdk-edgemedia-android#71
• Edge Bridge adobe/aepsdk-edgebridge-android#51

Epic description

Context:
There can be use-cases where an extension handles a certain event which generates an experience event and we should have a way to connect the two events together, especially for debugging and representation in Assurance. One use-case is having an Analytics generic event triggering an experience event, another can be the Edge request-response pairing.

Requires: adobe/aepsdk-core-android#436

Implementation details:

• Set parentId on Edge responses, including both handles and errors
• Set parentId on getter request/response pairs (TBD - if this is not set ootb by Core)
• Evaluate the deprecation plan for requestEventId in favor of parentId
• Note: no changes are required on the request events generated by the public APIs as these are considered triggering events, or original parents.

Tasks

• #58

Task description

Add the @Jvmoverloads annotation to the public APIs for Java usage compatibility with parameter default values

Additional implementation details or code snippet(s)

No response

Release Edge v2.1.0

• Added path overwrite feature for edge requests
• Documentation changes

In CI, some functional tests are marked as "flaky". Investigate and make the tests stable.

Add testing support for Edge, Edge Identity, Consent APIs and Assurance integration with Kotlin.
See Java test app as an example.

Task description

Release latest fixes and feature support for request complete event
Provide staging build for messaging SDK integration testing
Includes release validation and publishing of the new library

Additional implementation details or code snippet(s)

No response

Task description

• Add setDatastreamIdOverride, setDatastreamConfigOverride methods to ExperienceEvent Builder along with tests
• Send edge requests with configOverrides in meta (pass original datastream ID in case of datastream ID override)
• Add Unit, functional tests

Additional implementation details or code snippet(s)

No response

Task description

Work with appropriate team to publish new test utils repo for Android

Additional implementation details or code snippet(s)

No response

Task description

Linked to adobe/aepsdk-edge-ios#407

In order to make integration test adoption as seamless as possible, we need to investigate barriers to adoption using the current workflow of GitHub Actions and challenges other teams may face

Additional implementation details or code snippet(s)

No response

Linked to adobe/aepsdk-edge-ios#408

Task description

Need to investigate the use cases across extensions that depend on Edge Network extension, and see if it is sufficient for Edge Network extension to own all networking related integration testing cases. That is, the ones dealing with NetworkRequest and HttpConnection

Additional implementation details or code snippet(s)

No response

Linked to adobe/aepsdk-edge-ios#406

Task description

The two main options are:

1. A shared repo that owns all integration tests for extensions, with the test utilities also residing there
2. Integration tests are owned by each respective extension, and they import the test utilities they need

Approaches for each case, in the given scenarios

Running for all extensions

1. Run the integration test repo job
2. Need to have the caller call each repo's integration test job (and handle orchestration, be able to listen for pass/fail, etc)

Running for specific extension

1. Given tests are grouped by extension, run only tests related to specific extension
2. Run the repo's integration test job

Local development

1. Pull the integration tests into local project and run. If changes to integration tests are required, need to go to a separate repo to make updates
2. Run the integration test suite (as it is already part of the project)

Additional implementation details or code snippet(s)

No response

Additional implementation details or code snippet(s)

No response

Linked to adobe/aepsdk-edge-ios#410

Task description

Update the integration test workflow for resilience when running very frequently, and to only emit errors when true test case errors are encountered, not in cases like:

1. GitHub Actions runner failures/unavailability
2. Emulator/simulator startup failure, not found etc
3. Dependency fetching errors
4. Any other workflow related errors

Will need to test when run very frequently (maybe on some cron schedule?)

Additional implementation details or code snippet(s)

No response

Task description

Add integration testing workflow to staging and main PR check flow.

Additional implementation details or code snippet(s)

No response

Linked to adobe/aepsdk-edge-ios#409

Task description

Need to determine the per run cost of an integration test along the following metrics:

1. Machine type/size
2. Average/expected job runtime
3. Number of times to run in given time period (ex: 24 times in a day)

Currently GitHub Actions minimum spec runners for public repos is unlimited, but if this changes we need to be ready with the known cost implications

Additional implementation details or code snippet(s)

No response

Task description

The existing functional and integration tests should be refactored to use the newly available common test utilities available in: https://github.com/adobe/aepsdk-testutils-android

With the following items covered:

1. Any changes required to the common test utils should be opened as a PR to the test utils repo, optimally in a non-breaking change manner (although before the 1.0.0 release of the test utils, larger changes should be ok)
2. Manual dictionary/array property assertions should be refactored to use the JSON comparison tool
3. Test utilities that exist in the test utils repo should be used over equivalent test util classes defined locally

Additional implementation details or code snippet(s)

No response

Task description

Implement the test cases for the integration testing based on the test plan.

Implement a hybrid assertion testing strategy for validating the integration with the upstream:

1. Network request details - assertions done on HttpConnection object for things like HTTP code
2. Response payload details - assertions done by capturing the response events that are sent through the Event Hub using testing listeners with wildcards and/or specific event type+source values

Additional implementation details or code snippet(s)

No response

Task description

Provide test app and update docs on using Edge.sendEvent API for path / view changes in pure Jetpack Compose apps.
Update Edge kotlin-app: the app should have multiple screens and should be implemented with Compose Screens and Navigation.

Additional implementation details or code snippet(s)

No response

Task description

Dod:

• Set parentId on Edge responses, including both handles and errors
• Set parentId on getter request/response pairs (TBD - if this is not set ootb by Core)
• Automated testing

Additional implementation details or code snippet(s)

No response

Task description

Include params:

• optional unique identifier for the run
• required Edge environment (prod, pre-prod, int), default empty string (prod)
• optional location hint

Update the makefile and internal test framework code to read these values. These values should be passed in as test run params, without file modifications.

Additional implementation details or code snippet(s)

No response

Linked to adobe/aepsdk-edge-ios#411

Task description

We want to provide the:

1. JSON comparison system
2. Event test capture and assertion system (TestBase + InstrumentedExtension)

For general availability to other extensions to use in their own test suites. Investigate what is required for publishing as a separate module from the base Edge extension itself (like AEPServices from AEPCore)

Since the use case is for testing only, the size of the module itself is not as much of a concern

Additional implementation details or code snippet(s)

No response

Prerequisites

• This is not a Security Disclosure, otherwise please follow the guidelines in Security Policy.
• I have searched in this repository's issues to see if it has already been reported.

Feature request summary

With streaming connections it's currently not possible to know if the current handle being processed is the final handle for a given request.

We'd like to optionally set a value in a request Event that will cause the Edge extension to dispatch an Event back to the event hub once the streaming connection has been closed for the same request.

Current behavior

No response

Expected behavior

No response

Additional implementation details or code snippets

No response

Epic description

Create an automation framework library that can be shared across multiple mobile extensions.
Depending on the evaluation result on type of utilities used across extensions, support can include integration tests framework including advanced JSON comparison system, functional tests and/or unit tests utilities.

Port over full set of APIs from iOS.

Tasks

• #105
• #110
• #107
• adobe/aepsdk-testutils-android#3
• adobe/aepsdk-testutils-android#2
• adobe/aepsdk-testutils-android#1

Prerequisites

• This is not a Security Disclosure, otherwise please follow the guidelines in Security Policy.
• I have searched in this repository's issues to see if it has already been reported.

Feature request summary

Enabling the ability to specify a custom starting point in the actual side JSON hierarchy will allow test writers to make the testing intent more clear:

1. The actual JSON does not have to be manipulated
2. The expected JSON does not need wrapper containers to match the hierarchy of actual

This supports the use case of test case validation that is only interested in a specific child node in the JSON hierarchy onwards. With the change, the user no longer has to maintain the JSON hierarchy outside of what they actually want to validate

Current behavior

For example, in the current system given
actual

{
  "level1": {
    "level2": {
      "level3": 3
    }
  },
  "key1": 1,
  "key2": 2
}

your expected would have to be:

{
  "level1": {
    "level2": {
      "level3": 3
    }
  }
}

Expected behavior

With this new proposal, it could be:
actualStartPath: "level1.level2" +

{
  "level3": 3
}

Additional implementation details or code snippets

No response

Task description

Add support for extensions to overwrite path for edge requests.

1. Check for custom path experience event data
   Format:

   "request": {
       "path" : {custom path}
       }
   }
   

   EdgeMedia Example:

   "request": {
       "path" : "va/v1/sessionStart"
       }
   }
   

2. Overwrite the path based on values found for path in the experience event data
   Endpoint Format: https://edge.domain/ee/{custom path}
   EdgeMedia Endpoint Example: https://edge.domain/ee/va/v1/sessionStart

3. Add necessary Unit and Functional test

Additional implementation details or code snippet(s)

Sample EdgeMedia Experience Event:

"id": "93D05BBC-E5E3-88AF-AECB-5B224BDC80C1",
"name": "EdgeMediaTrackExperienceEvent",
"type": "com.adobe.eventtype.edge",
"source": "com.adobe.eventsource.requestContent",
"data": {
    "xdm" : {
        "mediaCollection" : {
            "sessionDetails" : {
                "ID" : "bipbop",
                "isDownloaded" : false
                "channel": "EdgeMedia-iOS-channel",
                "length": 1800,
                "name": "Bip bop video",
              "resume": false
                "sdkVersion" : "v1.2.3",
                "streamType" : "vod"
             
            },
            "playerEventDetails" : {
                "playhead" : 1
            }
        },
        "timestamp": "VideoEventTimeStamp"  
    }
    "request" : {
            "path" : "va/v1/sessionStart"
    }
}
"timestamp": "2022-07-21 21:46:18 +0000",
"responseId": nil,
"mask": nil
]

Final path for corresponding Edge Request:

`https://edge.domain/ee/va/v1/sessionStart`

Task description

• Update version in github docs
• Enable Integration tests after PDCL-11131 is fixed
• Manual e2e tests for the datastream ID override and datastream config override
• Smoke test builds
• Release

Additional implementation details or code snippet(s)

No response

Epic description

Enable integration testing with upstream services that can be triggered remotely.

Tasks

• #63
• #64
• #65
• #66
• #67

Task description

• Deprecate the setDatasetIdentifier function in favor of setDatastreamConfigOverride feature.
• Discuss and decide changes for XDMSchema class which takes in datasetIdentifier.

Additional implementation details or code snippet(s)

No response

Task description

Release Edge v2.2.0

• Adds event chaining support: Issue #58
• Fixes eventIndex location in response errors and warnings: Issue #68

Additional implementation details or code snippet(s)

No response

Epic description

Implement Datastream Override feature for aepsdk-edge-android

Tasks

• #98
• #99
• #100
• #117

No response

Task description

• Add upstream and E2E integration tests
• Add negative cases and handle errors from Konductor

Additional implementation details or code snippet(s)

No response

Task description

Currently the JSON comparison assertion public APIs are too permissive where they allow for any incoming types:

1. It's more confusing at the call site what types to use
2. It allows for known invalid comparisons (at the call site)

An immediate solution could be only allowing JSONObject == JSONObject and JSONArray == JSONArray comparisons as the API param types

A future looking solution could be something like creating a sealed class (that works like a union type) that can create a better type interface for mixing and matching types, especially if the feature of allowing custom validation start point paths is implemented

Additional implementation details or code snippet(s)

No response

Use the JSONUtils and MapUtils that were moved in Core and remove these helpers from Edge extension - ref adobe/aepsdk-core-android#328