Some matchers need to know about the current "negate status"

0 views
Skip to first unread message

Rodrigo Manhães

unread,
Dec 9, 2010, 10:46:17 PM12/9/10
to should-...@googlegroups.com
Hi all,

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

Hugo Lopes Tavares

unread,
Dec 12, 2010, 9:06:16 PM12/12/10
to should-...@googlegroups.com
I was thinking if we have another alternatives, but for what I see we don't.

That's ok to me, as is.

And the code is very clever ;-) Congratz.

Reply all
Reply to author
Forward
0 new messages