What's going to be the implementation strategy for this integration test? I'd be happy to use my current momentum with REST Catalog to implement the rest of the tests.

My current approach would be to migrate the test_rest.py unit tests from mock to the integration test, but I'm wondering if there's any changes or additions we could include in our new integration test flow. Let me know your thoughts

My current approach would be to migrate the test_rest.py unit tests from mock to the integration test

I think thats a great first step! Generally, testing via mocked requests is not as resilient as testing against a REST server. Let's move all the mocked tests into the integration rest test.

Would you like to work on this?

Sounds good! Yes, I'll work on it

(New to PyIceberg, so just spitballing here 😄)

@kevinjqliu, have we ever considered taking an approach similar (at a high-level, of course - some details don't transfer over to Python) to the Java-side that has CatalogTests? This is a base integration test class; various Catalog implementations have integration tests that override it (with additional tests if needed and some disabled). It can also be wired up with a REST Catalog. In this way, a bunch of expected Catalog behaviours can be verified with various catalogs (and REST wiring can be checked too).

I noticed a bunch of duplication between Glue and Dynamo integration testing here and here respectively that made me wonder why there aren't tests on a PyIceberg Catalog that can be run against them all. Happy to open a separate issue if this makes sense to you.

have we ever considered taking an approach similar (at a high-level, of course - some details don't transfer over to Python) to the Java-side that has CatalogTests?

Yes thats a great idea. The REST TCK (Technology Compatibility Kit) was merged recently apache/iceberg#10908
The idea is to point it at a REST server and check its behavior against the REST API spec.
So we can test the pyiceberg rest catalog implementation against the catalog tests from the java side.

I noticed a bunch of duplication between Glue and Dynamo integration testing here and here respectively that made me wonder why there aren't tests on a PyIceberg Catalog that can be run against them all.

I think this is a separate but important issue for pyiceberg. I want a set of tests which can be based off the catalog base class. The idea is to make it easier for new catalogs to test the base behaviors. This would be helpful for S3TablesCatalog (#1429).
I had #813 open to track something like this.