Support unittest.mock.ANY in header comparison

[dimaqq]

I'm testing a starlette app, let's pretend it's httpbin:

async def test_no_auth(client, services):                                               
    r = client.get("/bearer")                                                           
    assert r.status_code == 401                                                         
    assert r.headers == {                                                         
        "access-control-allow-origin": "*",                                             
        "access-control-allow-methods": "*",                                            
        "access-control-max-age": "86400",                                              
        "content-type": ANY,                                                            
        "x-content-type-options": ANY,                                                  
    }     

This fails with E AttributeError: '_ANY' object has no attribute 'encode'

For now I work around this by "casting" the magic header dict to an actual dict:

async def test_no_auth(client, services):                                               
    r = client.get("/bearer")                                                           
    assert r.status_code == 401                                                         
    assert dict(r.headers) == {                                                         
        "access-control-allow-origin": "*",                                             
        "access-control-allow-methods": "*",                                            
        "access-control-max-age": "86400",                                              
        "content-type": ANY,                                                            
        "x-content-type-options": ANY,                                                  
    }     

Then the comparison works and test is happy.

[tomchristie]

For now I work around this by "casting" the magic header dict to an actual dict

Hrm. Should we resolve this (which would mean adapting how we handle __eq__ specifically so we can deal with this case) or should we treat this as a reasonable constraint?

[dimaqq]

I feel that magic comparisons are a bit too magic from the library user perspective.

They are probably fine from the library developer perspective through.

[tomchristie]

🧐