-
Notifications
You must be signed in to change notification settings - Fork 2.4k
Dictionaries Should Be Equal
should support ignoring keys
#2717
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
Comments
Other problem is if we have list value for any specific key and we want to compare it with same key in other dictionary, both list should be identical. Order should be exactly same. Current keyword does not return true for UN-ordered list. In above example we have two keys with values in list. "abcd" : ['I','Love','Robot', 'Framework'], it will not match if we have following two keys in actual dictionary "abcd" : ['Love','I','Robot', 'Framework'], My above proposed keyword will take care this as well. |
Ignoring keys sounds useful, but I think it's better to enhance the existing I can see that ignoring order of internal lists can be useful too, but I'm not sure is it an often enough needed feature to make sense to add it. Similarly we could argue that support for ignoring duplicates in an internal list or making some internal validation case-insensitive could be useful, but adding keywords or optional arguments to handle all such cases is not possible. Collections library should support getting an internal list from a dictionary and having other keywords then for validating it in un-ordered manner. In other words, we could enhance list related keywords in Collections to support it. Notice also that if you have complex data structures, it's often easiest to implement custom keywords for handling them. |
We actually already have #2703 about ignoring list order. |
Developed new keyword that compare two dictionaries. For time being, I have kept keyword name as Also if you provide optional list of keys as parameter which will be ignored while comparing dictionaries. It will not check key and key value of ignored keys and keyword will pass if remaining keys are matching.
Please check the output of tests [in following archive file ] which are starting with TC |
FYI we use jsoncompare.are_same for this. |
Dictionaries Should Be Equal
should support ignoring keys
Are you @bbpatel2001 still interested in this one? I took a quick look at the PR and it seemed pretty complicated. |
I suppose the keyword, 'Dictionary Should Contain Sub Dictionary' can be used in some situations. |
this library written by me may help |
Hi, can I try taking up this issue? |
Thanks @yuriverweij for a great PR! I had missed it earlier but merged it now, just in time for RF 6.1. There are few smallish things, mentioned in the PR review, that I'll still fix. |
Problem:
Current implementation of "Dictionaries Should Be Equal" returns true if two dictionaries are identical. Sometimes we need to compare two dictionaries by ignoring some keys. i.e. If we have large dictionaries and one dictionary does not have some keys at nth level but still keyword should return True for all other keys if matches . Take example of following two dictionaries. expected_dict is my expected dictionary and Actual dictionary is created from UI data. Actual dictionary does not contain "Forged Source" key. If key is 1st or 2nd level we can pop key and compare it but if we want to ignore any key which is at the nth level it is very difficult.
I am proposing
new keyword "Dictionaries Should Ignore And Equal"
that will take three parameters: (I am OK to change name of keyword if accepted this proposal. )
1st parameter : Actual dictionary [Type: Dict]
2nd parameter : Expected dictionary [Type: Dict]
3rd Parameter : Ignore list [Type: List] : List of keys to be ignored
This keyword will not match key which is listed in third parameter
Dictionaries Should Ignore And Equal | d1 | d2 | ['Forged Source'] This will return True
I will add few more example if required.
The text was updated successfully, but these errors were encountered: