-
Notifications
You must be signed in to change notification settings - Fork 69
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
Add convenience methods for MapEntry assertions #117
Conversation
- containsEntry(K key, V value) - doesNotContainEntry(K key, V value)
This is really, really nice. Thanks Sam! Also, thank you for kind words about FEST :) We are in the middle of a mega huge refactoring. Once we are done, I'll merge this pull requests. Cheers, |
I'll be removing the method includes(Entry) after merging your pull request. |
I like the idea, it makes it easier to check for entries than with MapAssert.entry parameters. Map<String, String> address = ....
assertThat(address).hasSize(15)
.containsEntry("zip", "43865")
.containsEntry("lastName", "Frazier")
.containsEntry("state", "IA")
.containsEntry("city", "Culloden"); Moreover, we should also change |
Awesome, thanks Alex. Let me know if you have any issues applying the patch after the refactor Sam |
Good point Joel! I agree with you. Thanks Sam. I'll let you know if I find any issues while merging it. |
so what about the refactoring and this pull request? will it be merged soon? |
Alex is making a huge refactoring, contributions are in a pending state for the time being ... |
Hi, First of all please take into consideration that includes() method error message is hard to read for multiple parameters that have different values. So instead we have asserting invidual keys:
Although such code looks very repetetive. I have lately came up with similar idea as mentioned in this issue, although I have prototyped different API, which look like this:
Although there would be limitation to single predicate per entry, but we could simply return a subclass of AbstractAssert, so we could have a much grater flexibility. If you like to I could prepare a pull request for that. |
I really like this idea. I wonder if it would be worth renaming the entry()
On Wednesday, March 27, 2013, Jakub Narloch wrote:
|
I like the latest ideas, I will probably add them in AssertJ core. Regards, Joel Costigliola |
Quite often, I find myself testing map entries in the following way:
This change allows me to simplify the map assertions by getting rid of the repeated MapAssert.entry calls:
Please let me know if there's anything I can do to clean up the request!
Thanks for all your work on FEST! Assert and Reflect are life savers!
Sam