The problem is such an assert contains side effect and modifies the input queue which I think is a bad practice for writing assertions to be used in unit tests.
Modifying the queue during the assert is fine, assuming that this test is the only bit of code with a reference to the queue.
One common practice in designing tests is to use a single assertion to verify the behavior at the end of the scenario, so an assertion that destroys the utility of the queue when it is measured isn't necessarily a problem.
It's not ideal, either: "asking the question shouldn't change the answer". But not all API are designed with that goal in mind, and you may need to make trade offs.
Is using implementation details to traverse the queue without modifying it better?
Not usually, no -- especially not if you are intending the test to be a design aid that allows you to vary the underlying implementation (aka test driven design).
What may help is to have it clear in your mind what the required behavior is, and then to write clear descriptions of the behavior and verify that's what is observed.
You may find that Kevlin Henney's Recently Used List demonstration helps to clarify the distinction.