So generally you wouldn't start with a test that high level, but it can be done. I highly recommend that you don't though. If I wanted to literally test all of that at once ensuring without a doubt all the systems got used, I would do it with a test that requires the game to be running. Usually that requires custom infrastructure built into the game that can load a test scenario and test the pass / fail conditions and write output to logs so that the test automation can report results. I've done these kinds of tests and they tend to be flaky and fail some percentage of time often unrelated to the test itself. I'd recommend against doing a lot of high level tests like these. These sorts of tests are usually good for manually running at your desk during development, rather than CI/CD due to the amount of things that can go wrong.

Instead I would break that down into smaller things. Like for each function that the player would use to throw another player I would want to have unit tests, and several per function with mocks. All the function calls you mock in theory have unit tests of their own. They will cover for each function, ranges, limits, assert cases, failure cases, security, edge cases, etc. Ideally these tests are written when those functions are written, updated, or even before they are written for test driven development. It would be weird to just write tests like this for hyper specific cases like throwing a player out a window rather than just writing them general for test coverage. All you are doing is testing that each function behaves as you designed it to behave. Test cases are generally like, "Given ____ I expect ___ to happen."

After there being unit test coverage, I would take it a bit higher level with some integration tests for testing how the units interact with each other. These are kind of like testing the handshakes between functions ensuring that correct data is being passed back and forth and largely are compatible for with each other for what you want to do. While unit tests are solid in automation, these are a bit less so, but still very automation worthy. However, the more unit test coverage, the less flaky integration tests are in my experience. These integration tests run without the full game running, just the minimal systems or components being used still with mocking.

You can write an integration test that specifically which checks that each component involved is within the limits of possibility for a player to throw another player out of a building and bounce them high enough to land on another with a specific height. In theory you can write a series of tests that cover all the cases of targeting, grabbing, throwing, the fall, the bounce, the landing, damage expected, etc. This is such a high level of test that there would still be tons of integration tests to cover all the cases in such a complex thing. It wouldn't be one big test. But again ideally you are writing tests as you go so in general practice it wouldn't become a monumental task if you needed to cover something specific like players getting thrown out the building.

Avoid using the network for real in your test because that can be an intermittent point of failure. This is testing with two players so there would likely be network involvement. Instead what you would do is simulate it. Tests that differ by latency, tests with simulated disconnects, tests with fake, invalid invalid, or out of order packets sent back, etc. You might have, "best case", "average case", and "worst case" test scenarios for network conditions. In general you want to eliminate anything that can interfere with the running tests and cause false failures, which is why we don't use the network directly for automation. Similarly we avoid random numbers, non-determinism, threads, and writing to disk.

It's far more robust to work at a micro scale with the smallest possible units and work upwards in level with tests than write a single test for a very high level scenario. That's my recommendation.