_categories = "womensclothingtops|10,salewomensclothingtops|9" Plain JSON diff doesn’t provide enough context as shown below: -6,7 +6,6 " JSON diff is not a very efficient way of consuming the data, so we flatten the JSON diff and produce it in an easy to read format. We want the output of comparison testing to be generated in a way that is easily consumable by our Quality Assurance team.
#Json compare ignore order code#
Any anomaly ensures that the problem is in our code changes since the rest of the environment involving configs is constant. Then we hit both these endpoints with the selected URLs, collect the responses and compare them. We replicate the production environment and deploy our new release on it. We have our production environment having current release. Return _weight(queries), parsed._replace(query=urllib.urlencode(queries, True)).geturl() Queries = urlparse.parse_qs(parsed.query) Below is a code snippet for calculating weighted average:įor key in ('unwanted_param_1', 'unwanted_param_2', 'unwanted_param_3'): This increases the coverage of API features. Weights are assigned to these parameters and a weighted average is taken, where a request with greater weight is given preference.
Selected URLs are based on the presence of our URL parameters, like sort, facet range, and filter query (fq), etc. We randomly pick one-tenth of the requests from our production log in the last 24 hours and generate unique valid URLs. The below figure illustrates this mechanism and each step is elaborated in further sections: We then collect the responses from both the endpoints and generate a report showing differences in the JSON responses. One endpoint is the production environment serving our customers and the other one is a replication of our production environment having the new release. To ensure the quality of our serving, the engineering and QA teams do comparison testing of these APIs by randomly selecting frequent URLs across all the merchants and testing the API layer with our new release candidate by hitting two endpoints. With Bloomreach serving more than 300 customers supporting about 1600 QPS for Search and Personalization APIs, 3000 QPS for Suggest APIs and more during the holiday period, we cannot afford to break our serving by deploying a buggy release. This helps in predicting the behavior of new release in production and ensures the quality and stability of the release. So comparison testing of APIs is added in the release process, where the production environment is replicated, a new release is deployed on it and APIs are tested. Due to the parallel development of many features, existing unit and integration testings were not sufficient. At Bloomreach, quality is a primary focus for releases.
0 kommentar(er)
