Create JSON comparison API migration docs #1062
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
cacheung
reviewed
Aug 8, 2024
| Both APIs allow for passing in any number of path options, which are customizations you can apply to the JSON comparison logic. The following options are available: | ||
|
|
||
| - **Multiple paths** can be used simultaneously. | ||
| - **Multiple path options** are applied sequentially, and if an option overrides an existing one, the overriding occurs in the order the path options are specified. |
There was a problem hiding this comment.
does this mean the later path options can overrides the earlier path options?
There was a problem hiding this comment.
Yes, only if they are the same option and they conflict with each other! For example if the following options were applied to the same call:
assertExactMatch(expected: expected, actual: actual, pathOptions:
CollectionEqualCount(paths: "key1.key2", isActive: true, scope: .subtree),
CollectionEqualCount(paths: "key1.key2", isActive: false, scope: .singleNode))the "final" path option for CollectionEqualCount would be the second one (since the path they're applying to are the same)
| assertExactMatch( | ||
| expected: expected, | ||
| actual: actual, | ||
| pathOptions: KeyMustBeAbsent("key1"), CollectionEqualCount(scope: .subtree)) |
There was a problem hiding this comment.
As discussed, let pick a more straight forward path option than CollectionEqualCount for this example
There was a problem hiding this comment.
Thank you! Updated to use ValueTypeMatch with a basic path instead
|
|
||
| Each section below explains the key pattern to look for in your test case when migrating to the equivalent JSON comparison API usage. | ||
|
|
||
| ### Default value exact vs type match |
There was a problem hiding this comment.
Should we swap
Default value exact vs type match
and
Equals validation
Sections?
After reading the description for ### Default value exact vs type match, I was expecting more context related to this. But the next one is Equal validation, which isn't flow well.
There was a problem hiding this comment.
Thank you! That sounds good to me, I've switched the order - please let me know what you think
| ``` | ||
|
|
||
| This pattern is commonly encountered when performing JSON payload validation with randomly generated or time-based values, such as ECIDs or timestamps. By using only value type validation on these values, the correct type can be validated without needing to pre-capture the actual value. | ||
|
|
There was a problem hiding this comment.
Do we need an example of
assertTypeMatch( // Base value comparison mode is Type match
expected: expected,
actual: event,
pathOptions: ValueExactMatch(paths: "key1")) // Enables to check exact value for "key1" match for the specified path
There was a problem hiding this comment.
That's a great point, I agree it would be valuable to show both ways of doing it - I've added another example to this section using the example you suggested
Reorder migration patterns sections Add additional example using type match as default for mixed exact vs type match validation section
2 tasks
praveek
added a commit
that referenced
this pull request
Aug 30, 2024
* Initial setup for AEPTestUtils as local module within Core * Update AEPTestUtils podspec configuration 1. Version to 5.0.2 2. Homepage to point to Core repo URL 3. License format to match all other podspecs in Core 4. Source to point to Core repo URL 5. Source files point to PublicTestUtils under Core and Services 6. Core and Services dependency restricted to 5.2.0 < 6 * Create contribution guide for AEPTestUtils * Add more info for how to add test helper files in AEPTestUtils contribution guide * Create AEPTestUtils specific version update script and workflow action * Workflow debug steps * Add more debug steps to workflow * Update shell * Fix version taken from workflow input * Update sed command usage * Version script updates * Script updates * fix workflow script * Update workflow * Rename AEPTestUtil version script and workflow file names for clarity Remove debug prints from both files * Update dependencies update logic * Revert "Update dependencies update logic" This reverts commit 6fc046f. * Use per dependency check instead * Create Package.swift for AEPTestUtils * Revert "Create Package.swift for AEPTestUtils" This reverts commit 52a0561. * Revert copyright year to original * Add back existing files * Try to trigger cache miss * Fix incorrect project target AEPCoreMocks Compile Sources file paths for some files * Revert "Try to trigger cache miss" This reverts commit a8f6801. * Update TestUtils contributing guide documentation for clarity * Consolidate version update script, adding logic to handle TestUtils specific flow * Update TestUtils version workflow to use updated version script * Bump AEPTestUtils podspec version * Create podspec verification script for AEPTestUtils * Create test workflow to run AEPTestUtils podspec check script * Remove the dependency on internal AEPServicesMocks in public AEPTestUtils files * Update AEPCore and AEPServices podspecs to allow for ENABLE_TESTING_SEARCH_PATHS * Fix testable flag in AEPCore and AEPServices podspecs * Try adding ENABLE_TESTING_SEARCH_PATHS flag to AEPTestUtils * Try adding ENABLED_TESTABILITY flag to AEPTestUtils podspec * Fix typo in podspec 'ENABLE_TESTABILITY' flag * Update podspecs to use test target * Try different flags for AEPTestUtils * Try different flags for AEPTestUtils * Tweak AEPTestUtils flags * Update validation script to use test target instead of regular * Check removing custom flags * Remove custom flag stuff from podspecs * Create release workflow for AEPTestUtils with validation as a prereq * release_testutils.yml - Fix script path and temp disable main branch check * release_testutils.yml - add step to install xcodegen * release_testutils.yml - update runner to macos and add version format validation * Update podspec_version logic * temp disable podspec validation * Add git author information * Testing removing git author and reenabling main branch if * Hardcode `main` branch for release_testutils workflow Reenable all steps * Remove temp workflow * Add makefile rule for testutils podspec validation and update workflow usage * Temp disable main branch checkout * Reenable main branch checkout * Revert "Remove the dependency on internal AEPServicesMocks in public AEPTestUtils files" This reverts commit 58c3687. * Revert "Remove temp workflow" This reverts commit ef41e52. * Remove test workflow again * update-versions.sh - Remove multiplatform sed compatibility in favor of original macOS version Update testutils version workflow to use macOS runner * Apply latest AEPTestUtil updates (5.1.0) (#1057) * Bring over latest AEPTestUtils changes (since 5.1.0) * Make utilities Threadsafe * Update AEPTestUtils version to 5.2.0 * Improve AEPTestUtils Network Service helper class multi thread handling and method docs (#1058) * NetworkRequestHelper.swift - Reorder methods by functionality, update method docs, add deprecation to flatten map method * RealNetworkService.swift - Update method docs and method ordering * MockNetworkService.swift - Update method docs and method ordering * NetworkRequestHelper.swift - Update method to perform await outside of sync block * NetworkRequestHelper.swift - Update to use Log and add error log for invalid URL string * Update JSON comparison APIs (#1059) * Remove deprecated APIs and add support for new path options * Add support for new path options ElementCount and ValueNotEqual Remove deprecated logic and path interpretation logic Reorder methods based on usage and dependency * Enhance test failure messages and update variable name from wildcard to accurate any order Update failure message strings to use regular multiline strings to reduce unused syntax * XCTestCase+AnyCodableAsserts.swift - Update code docs * Apply lint * Update access level to private * Create JSON comparison API migration docs (#1062) * Create JSON comparison API migration docs * Simplify path options usage example Reorder migration patterns sections Add additional example using type match as default for mixed exact vs type match validation section * Fix flaky Identity tests (#1061) --------- Co-authored-by: Praveen <praveek@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR creates migration docs for flatten map implementations to use the JSON comparison APIs, covering:
Related Issue
Motivation and Context
How Has This Been Tested?
Screenshots (if appropriate):
Types of changes
Checklist: