Yesterday, I began to implement a new matcher, include_key, that
ensures that a dictionary includes the given keys. In all matchers
that we've implemented until now, should_not was the perfect opposite
to should. But include_key doesn't act in this way. Let's see: the
code
{'a': 1, 'b': 2, 'c': 3} |should| include_keys('a', 'd')
will raise ShouldNotSatisfied. In the same way,
{'a': 1, 'b': 2, 'c': 3} |should_not| include_keys('a', 'd')
will raise the same.
With current Should class, there's no way to put this matcher to work
as desired. In this case, the matcher needs to know by what kind of
should it is being run: should or should_not.
Then, I changed the Should class in order to make it inject this
information into all matchers. I think it's a reasonable feature, but
I wanna hear the points from our core team before updating the
mainline with changes to Should-DSL core. So, I pushed the changes to
a branch in my fork:
https://github.com/rodrigomanhaes/should-dsl/commit/bed0d94785cf7eb93f16d8d0d9800f314c3ea36d
https://github.com/rodrigomanhaes/should-dsl/commit/b19c3cc679f557834276a349c15b338cf824796f
[]'s
Rodrigo
That's ok to me, as is.
And the code is very clever ;-) Congratz.