Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Presto needs a modern functional testing framework that runs tests using real infrastructure #23086

Open
tdcmeehan opened this issue Jun 26, 2024 · 0 comments · May be fixed by #23087 or #23094
Open

Presto needs a modern functional testing framework that runs tests using real infrastructure #23086

tdcmeehan opened this issue Jun 26, 2024 · 0 comments · May be fixed by #23087 or #23094

Comments

@tdcmeehan
Copy link
Contributor

Expected Behavior or Use Case

We should have a testing framework that tests real Presto configurations without relying on a query runner which mocks out external infrastructure interaction. This will help catch Guice wiring issues and protocol incompatibility with external infrastructure. This framework should be familiar and easy to write tests for in order to encourage more test coverage to be added to the project. Such testing should be included in release verification and should be tested periodically on trunk (although perhaps not for every commit due to cost concerns).

Presto Component, Service, or Connector

Testing

Possible Implementation

We can create new container classes for Presto Java coordinator, Presto Java workers, and Presto C++ workers. These new container classes can be integrated with existing frameworks that are widely used in our end to end tests to quickly provide test coverage over a wide variety of queries.

Example Screenshots (if appropriate):

Context

Most of our current functional tests use Tempto. This repository is practically unmaintained, with the last commit being over 3 years ago. Developers are not adding new tests that use this framework because it is difficult to use and understand.

Ideally, our functional tests should use familiar frameworks and concepts that are used in our existing tests in the main repository. Tempto was created before TestContainers became popular, and TestContainers solved many of the problems that Tempto was appeared to be designed to solve. However, it also has some benefits over Tempto:

  1. It is an independent community, which means lots of open source infrastructure is readily available as a pre-made test container. This means it should be easier to add new functional tests for open source infrastructure (e.g. MySQL).
  2. Using TestContainers, we can use our existing TestNG testing framework, and existing assertions. The coding style for TestContainers based tests will be similar to existing end to end tests written in Java, which will hopefully encourage more tests to be added.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant