Issue #1 open

expect('foo') in 'foozilate'

Kumar McMillan
created an issue

it would be pretty sweet if the expect object supported in() so you could get nice messages for substring expectations. Would need unicode support too (thar be dragons).



expect('foo') in 'foozilate' expect('を') in 'ページを閲覧中にクリック一つで使える豊富な開発ツールを' }}}

Comments (2)

  1. Gary Bernhardt repo owner
    • changed status to open

    I've thought about the containment issue quite a bit. That syntax won't work because there's not an in, only a contains. In your example, 'foozilate'.contains will be called and there's nowhere to hook an assertion in.

    We could define contains to at least make expect() work on the RHS, but that breaks the fundamental rule of Expecter Gadget, which is that you always put the actual value in expect() and it always starts the line. :)

    I think my preferred solution is to add predefined, named expectations: maybe "expect('foozliate').to_contain('foo')" and "expect('foo').to_be_in('foozilate')" or something like that. I haven't done it because I haven't found names that seem right yet, though.

  2. Kumar McMillan reporter

    ohhh, I didn't realize it needs __contains__ on the target. Hmm I also didn't realize the the argument to expect() should be the actual value, that makes sense. I always use this mess of code but it's stupid:

    s = 'foozilate'
    assert 'foo' in s, ('Unexpected: %r' % s)

    So per your comments my vote is for:


    PS. I forgot about expecter until your tweet! It's nifty.

  3. Log in to comment