Update with latest dev changes#364
Update with latest dev changes#364emdobrin merged 37 commits intoadobe:feature/upstream-integration-testsfrom
dev changes#364Conversation
* Remove deprecated class XDMFormatters * Update timestamp field in MobileSDKCommerceSchema in tutorial apps
…nsion version Bump to 4.0.0 (adobe#344) * Update Min supported version to iOS 11 and tvOS 11. Bump major extension version. * Clean Makefile and add steps to generate xcframeworks * Update Github release workflow to add XCframework with the release * Add ci steps back in Makefile * Fix Github workflow steps * Updates based on reviews * More review updates * Update README * Add version to the release artifact * Update the getting started doc * Add test command in Makefile to run ios and tvos tests * Update makefile * Add commands to remove exisiting coverage reports before running the tests * Update Makefile * Add usage sample in comment for check-version command * Update all extensions to version 4.x * Remove empty marketing versions * Update podspec version to 4.0.0
* Update Podfile to use Core staging and Edge* dev branches * Update SwiftLint version 0.52.0 * Fix format after SwiftLint update
* Update Podfile to use Core/Services production version * Update podfile for Tutorial apps
Merge to Staging for 4.0.0 release
Staging -> Main v4.0.0 release
Update dependencies to prod and links
downmerge main -> dev
* Code changes for chaining parent event to network response events * Add functional tests for event chaining * Update method comments, rename parameter to 'parentRequestEvent' * Rename variable 'requestParentEvent' to 'parentRequestEvent'
# Conflicts: # Makefile # Podfile.lock # README.md # Tests/FunctionalTests/NetworkResponseHandlerFunctionalTests.swift
dev changesdev changes
Codecov Report
@@ Coverage Diff @@
## feature/upstream-integration-tests #364 +/- ##
======================================================================
+ Coverage 96.54% 96.73% +0.19%
======================================================================
Files 28 27 -1
Lines 1649 1653 +4
======================================================================
+ Hits 1592 1599 +7
+ Misses 57 54 -3 |
| // Wait .2 seconds in case there are unexpected events that were in the dispatch process during cleanup | ||
| usleep(200000) | ||
| // usleep(200000) | ||
| sleep(1) |
There was a problem hiding this comment.
this change will increase the test run time with 1 sec times no of tests, what are those events that are blocking for so long before the cleanup?
There was a problem hiding this comment.
I was thinking this would catch the failure case from #365 -> 1. Test cleanup failure, as there appears to be some order dependent test failures
However, I've reverted back to the original time in hopes it will be sufficient
| waitForRegistration.countDown() | ||
| }) | ||
| XCTAssertEqual(DispatchTimeoutResult.success, waitForRegistration.await(timeout: 2)) | ||
| XCTAssertEqual(DispatchTimeoutResult.success, waitForRegistration.await(timeout: 10)) |
There was a problem hiding this comment.
I would think even 2 sec is a lot for registration, do you know aprox. how long it actually requires to run on CI?
There was a problem hiding this comment.
Based on the logs it seems like consistently less than a second
Looking at the logs again for test setup failure cases, it looks like this class of test failure happens when the unit test build process is interleaved with the currently running functional test case (I have other examples, but only showing screenshots for testSendEvent_twoConsecutiveCalls_appendsReceivedClientSideStore to demonstrate)
Successful test setup
Failing test setup
When the test setup happens correctly (ex: this latest build), there is no unit test build interleaved
Should the greatly extended timeout be kept to account for this potential interleaving? Or is there a way to prevent the interleaving from happening?
Since the timeout wait can be satisfied early if all conditions are met, having a large timeout value should not affect runtime of most test cases right?
There was a problem hiding this comment.
update: we decided to split the test runs in two steps: unit and functional for each platform, see PR #368
timkimadobe
left a comment
There was a problem hiding this comment.
Thank you for the review @emdobrin! Updated based on feedback and added additional context, with some outstanding questions
| // Wait .2 seconds in case there are unexpected events that were in the dispatch process during cleanup | ||
| usleep(200000) | ||
| // usleep(200000) | ||
| sleep(1) |
There was a problem hiding this comment.
I was thinking this would catch the failure case from #365 -> 1. Test cleanup failure, as there appears to be some order dependent test failures
However, I've reverted back to the original time in hopes it will be sufficient
| waitForRegistration.countDown() | ||
| }) | ||
| XCTAssertEqual(DispatchTimeoutResult.success, waitForRegistration.await(timeout: 2)) | ||
| XCTAssertEqual(DispatchTimeoutResult.success, waitForRegistration.await(timeout: 10)) |
There was a problem hiding this comment.
Based on the logs it seems like consistently less than a second
Looking at the logs again for test setup failure cases, it looks like this class of test failure happens when the unit test build process is interleaved with the currently running functional test case (I have other examples, but only showing screenshots for testSendEvent_twoConsecutiveCalls_appendsReceivedClientSideStore to demonstrate)
Successful test setup
Failing test setup
When the test setup happens correctly (ex: this latest build), there is no unit test build interleaved
Should the greatly extended timeout be kept to account for this potential interleaving? Or is there a way to prevent the interleaving from happening?
Since the timeout wait can be satisfied early if all conditions are met, having a large timeout value should not affect runtime of most test cases right?
…d warnings (adobe#363) * Look for eventIndex in report object of error and warning in network response * Do not encode eventIndex in EdgeEventError or EdgeEventWarning objects
ab8dac3 to
f73c05b
Compare
Updating version to 4.1.0
* Split unit and functional test steps Update CircleCI script accordingly * Reorder unit and functional tests * Reorder unit and functional in cleanup step * Test reordering libraries * Split Makefile rules test-ios and test-tvos to run unit and functional tests separately * Run functional tests even when unit tests fail in CI * Move test reports under 'build/reports' folder --------- Co-authored-by: Kevin Lind <lind@adobe.com>
[CI] Sleep after EventHub.shared.start in API unit tests
# Conflicts: # Tests/FunctionalTests/NetworkResponseHandlerFunctionalTests.swift # Tests/UnitTests/EdgePublicAPITests.swift
| public override func tearDown() { | ||
| super.tearDown() | ||
|
|
||
| // unregisterInstrumentedExtension() |
There was a problem hiding this comment.
do we need this change or can we revert?
There was a problem hiding this comment.
looks like we don't unregister in dev branch either, likely because down bellow we call EventHub.reset() anyway, so that will reset all extensions before next test run.
So, can we remove this commented line then? And I am also curious where else we use this function unregisterInstrumentedExtension
There was a problem hiding this comment.
I think we can revert this change! I saw this API available in the TestBase class and just wanted to try it to see if it would address some of the flaky test issues (which ended up being caused by other things)
The unregisterInstrumentedExtension extension isnt used anywhere else that I could see
There was a problem hiding this comment.
Thanks for checking, changes look good to me. We can revisit this in the future and see if we can remove the unused API and the associated code in the InstrumentedExtension.
timkimadobe
left a comment
There was a problem hiding this comment.
Thanks for the review @emdobrin! Addressed feedback with latest update
| public override func tearDown() { | ||
| super.tearDown() | ||
|
|
||
| // unregisterInstrumentedExtension() |
There was a problem hiding this comment.
I think we can revert this change! I saw this API available in the TestBase class and just wanted to try it to see if it would address some of the flaky test issues (which ended up being caused by other things)
The unregisterInstrumentedExtension extension isnt used anywhere else that I could see
Description
This PR covers:
devchanges into the integration test feature branchdevchanges to use new testing framework and APIsUpdating some tests to have greater timeout tolerances for setup/teardown processRelated Issue
Motivation and Context
How Has This Been Tested?
Screenshots (if appropriate):
Types of changes
Checklist: