Stefano Pentassuglia

This issue has been solved by [this PR](https://github.com/stretchr/testify/pull/982) with the introduction of the `Unset` method

I think the cleanest way to handle this would be to have an additional field in the `Call` struct similar to [requires](https://github.com/stretchr/testify/blob/master/mock/mock.go#L80), that tracks the Calls that require the current...

I'm still not convinced that the cleanest approach would be to mark the call as satisfied. Faking something that didn't actually happen to satisfy the Unset logic sounds more like...

Yes I'd be happy to do it! Can you assign it to me? Tomorrow i'm going offsite for 10 days though, so i'll probably be able to complete it when...

I think this is intentional, because the implementation [here](https://github.com/stretchr/testify/blob/master/assert/assertions.go#L1382) only iterates the length of `actual`. Asserting that also all the elements of `expected` have a successful match in `actual` would...

Solved by https://github.com/stretchr/testify/pull/1261

I confirm what @tscales said, i can't reproduce the issue either. [Here](https://go.dev/play/p/uQQdunMp7uh?v=goprev) is a working snippet

This is already possible using the `Unset` method, as shown in [this example](https://github.com/stretchr/testify/blob/master/README.md?plain=1#L212-L216). I just tried it in [this sample test](https://go.dev/play/p/oXwEFdI8h_Q?v=goprev) and it worked, this is the output: ``` ===...

Any ideas on how this could be done without introducing breaking changes? I can't seem to find a solution that doesn't involve an extension of the surface of the library...

The only http assertions available right now are on the response status codes (`HTTPSuccess`, `HTTPRedirect`, `HTTPStatusCode`, etc) and body (`HTTPBodyContains`, `HTTPBodyNotContains`) (I hope this is what you asked, i'm not...