Hi Timo, Thank you for providing so many information.
- I have some my thoughts on end to end tests. I think such as Kafka, and elastic search . We can not run end to end tests in the IDE for debugging and set breakpoints. For those, we still need implement its logic in bash scripts like downloading software from an URL and do some stuff around it. - From a flink user endpoint. Users (at least for me (sometimes) and my friends) hopes RUN flink cluster as quickly as possible when the first time getting start to flink. I still remember the first time I use flink is I have to implement Elasticsearch as its sink. And I hopes I can find something like run scripts in flink-example or flink-end-to-end examples to start a flink cluster and make elasticsearch as a sink for me to learn. And at that time, I might be skip Quickstart and directly find Elasticsearech-related flink. But I can not find anything at that moment. - Last but not least, more examples, more better and keep it simple. I suggest keep Kafka and elastic search end to end test implements its logic in bash scripts as at this moment, it is very easy to understand for new user. ( Cluster, LogAnalyzer, WatchdogProcess, hmm, I would think it is a little hard for beginners to learn if we put it in Kafka, elastic search and third-party software downloads end to end test) Other than that, I think it’s okay. Cheers Mingleizhang > 在 2018年3月27日，下午8:00，Timo Walther <twal...@apache.org> 写道： > > Hi everyone, > > after reviewing a bunch of end-to-end tests, I'm wondering if we should > really continue implementing everything in bash scripts. Wouldn't it be nicer > to implement them in Java code that just calls the interfaces of Flink (e.g. > "./bin/flink run" or REST API)? > > Here are some thoughts why I think we should consider that: > > - Implement the tests in a more object oriented way: We could have classes > such as Cluster, LogAnalyzer, WatchdogProcess, and other utility classes that > can make writing tests easier. This also ensure maintainability in the future > because all tools for proper Java coding style, comments etc. are already in > place. > > - Exception handling and type safety: We could catch excpetion more easily > (e.g. if a REST request fails or a process is not there) > > - Debuggability: We could run end-to-end tests in the IDE for debugging and > set breakpoints etc. > > > What do you think? > > > Regards, > > Timo >
