liurenjie1024 commented on issue #519:
URL: https://github.com/apache/iceberg-rust/issues/519#issuecomment-2267279537
Hi, @fqaiser94 Thanks for raising this, and I'm definitely +1 for this
proposal to avoid duplicate codes!
About the overall design, inspired by your design, I think maybe we can have
origanize things like following:
```
struct CatalogTestSuite<C> {
catalog: C,
file_io: FileIO
}
impl<C: Catalog> CatalogTestSuite {
async fn test_catalog_create_empty_namespace(self) {
...
}
async fn test_catalog_create_empty_hierarchy_namespace(self) {
...
}
...
}
```
Then in each catalog tests module, we can just have tests to setup this
`CatalogTestSuite` and call different method in different case:
```
#[tokio::test]
async fn test_create_empty_namespace() {
let suite = CatalogTestSuite {}
suite.test_catalog_create_empty_namespace().await
}
```
With this approach we have boilerplate codes in each catalog test module,
but I think this is a trade off. We can use macros or
[libtest_mimic](https://docs.rs/libtest-mimic/latest/libtest_mimic) to remove
duplicate codes as much as possible, but the problem is that it makes running
single test in ide a little more difficult.
> The main concern I have is that the existing catalogs don't all follow
exactly the same behaviour, there are small, subtle differences in behaviour
like checking for tables before dropping a namespace, error messaging, etc. It
may or may not be worth aligning behaviours but we can discuss all of that when
we get there.
I think there are two problems here:
1. Not all catalogs support exactly all test cases. For example, IIRC, hive
catalog doesn't support nested namespaces, and rest catalog's support for
namespaces is not determined yet.
2. About the subtle behaviors differentct(such as check table), I think we
should align them, but we don't need to do them together, we can do them one by
one once we have finished the necessary preparatory work.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org
For additional commands, e-mail: issues-h...@iceberg.apache.org
