equal doesn't work well with call_args_list in voidspace mock

[fatuhoku]

According to the Voidspace mock documentation, you can verify that a method was invoked with specific parameters by doing:

>>> expected = [call(1, 2, 3), call(4, 5, 6), call()]
>>> mock.call_args_list == expected
True

The above example works and passes the test if put into an assert. i.e. the statement assert mock.call_args_list == expected is valid.

If I want to write the same thing in sure syntax, I get a failure. Let's say I want to write a test with this:

def test_oh_dear():
    # Set up the mock
    # Interact with the mock
    expected = [call(1, 2, 3), call(4, 5, 6), call()]
    mock.call_args_list.should.be.equal(expected) # !!! this line fails

The failure I get is:

     Failure/Error: given
     X = [...]
         and
     Y = [...]
     X is a _CallList and Y is a list instead

The contents of the arrays don't matter. I just find it inconsistent and counter-intuitive syntactically that == works with an assertion and .equal() does not!

[gabrielfalcao]

Hello @fatuhoku,

there is nothing exactly "wrong" with sure in this aspect of comparing mock call args list.
What happens is that the "equals" assertion in sure was designed to compare objects and data structures recursively through the DeepComparison class.

Because of that, objects might have their types compared.

I confess that I have come across the same issue you are having, and so I came across this experiment:

from mock import _CallList as CallList

def test_oh_dear():
    # Set up the mock
    # Interact with the mock
    expected = CallList([call(1, 2, 3), call(4, 5, 6), call()])
    mock.call_args_list.should.be.equal(expected)  # Success :)

I plan on creating some cool features in sure integrating specifically with mock because it's the best mock library IMHO.

Thank you for opening this issue :)

[fatuhoku]

Hi @gabrielfalcao

Thanks for clarifying. I take back saying that sure was 'wrong', that was a tad strong =]. You can tell I'm a bit of a novice to Python so that little factoid about DeepComparison was helpful.

I did discover your solution with _CallList but coming from a Haskell/Java/Scala/C# typed-language-land background it feels a bit dirty. So it's great that you're thinking of integrating with mock. I love mocking, mock gets me there but its syntax clunky to use at best.

A fluent interface over setting expectations (like what mockito tried to do) would be absolutely amazing. And a lot of work!

I take this opportunity to thank you for sure because it's made my tests really readable, and it really is the most awesome assertion library Python has today. =]

[clarete]

Hi @fatuhoku and @gabrielfalcao,

I really liked the idea, since we're always using sure and mock together. Although, I tend to say that it looks more like a feature request than actually a bug fix.

Anyway, I still think we should give an option to the user bypass this kind of integration. Use case? What if people start using sure to test mock itself? :)