You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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).
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.
The text was updated successfully, but these errors were encountered:
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:
The text was updated successfully, but these errors were encountered: