-
Notifications
You must be signed in to change notification settings - Fork 237
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discrepancies in the behavior of test runners for Mapping
and Service
#429
Comments
Mapping
and Service
Mapping
and Service
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment! |
This issue is stale because it has been open for 30 days with no activity. Please remove stale label or add any comment to keep this open. Otherwise this will be closed in 5 days. |
I believe this should be handled once we mapping is integrated into a testable mechanism - #866. |
@hardikmaheshwari Honestly, I don't recall much the context around this. It has to do with A worksaround we had to add in Studio as well. But I think what you said makes sense. Now that we use test dataand store data as |
This issue is stale because it has been open for 30 days with no activity. Please remove stale label or add any comment to keep this open. Otherwise this will be closed in 5 days. |
This issue was closed because it has been inactive for 35 days. Please re-open if this issue is still relevant. |
Mapping Test Runner vs Service Test Runner
Mapping Test
Mapping tests are currently run within Studio and SDLC pipeline. We haven't examined the pipeline mapping test runner, but for Studio, we do it by matching the hash of the actual data (created by building a test runtime and execute using the
execute
API) vs. the expected data.Service Test
Service tests are currently run using
doTest
api call method inengine
with test data and an assert lambda returning aboolean
. This assert function uses theequalJsonStrings
function inPure
.Discrepancies
Discrepancies arise when the same protocol definition of the service expected data and the mapping expected data produces different test results. The service test fails with the below while the mapping test passes. Notice both have been escaped to
\\'DATE_COL\\'
in the protocol JSON.Studio
is trying to make sure for either mapping test or service test, the assertion data strings are the same. However, as stated, this same string causes different response in the test runners. QUESTION: Is this is the intended behavior, should we fix either to match the other?So the question is, should we do anything about this behavior? This deserves its own Github issue, but I'm starting to think we can use
base64
for this.Model Grammar
Service protocol JSON vs. Mapping protocol JSON
The text was updated successfully, but these errors were encountered: