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
Rework the integration tests and setup to use exasol libraries (e.g. pyexasol or pytest-exasol) for preparing the DB
and setting up the tests written and maintained by exasol.
Details
Currently either SQLA, pyodbc, turbodbc or any combination of them is used to setup and prepare the test DB and it's
contents. This has at least two major flaws (shortcomings):
Chicken Egg Problem
While the core functionality of the exasol SQLA dialect is not working properly, it's very hard or impossible
to execute some or any tests with the appropriate DB and data setup.
It is not possible (without workarounds) to additionaly run integration tests which are not using the sqla test infrastructure.
⚠️ Problems ⚠️
* Test collection works differently (Tests won't get picked up)
* Test runs always need to provide db settings etc. to the sqla test plugin, otherwise the "pytest cli" will crash.
Eat Your Own Dog-food
We test and rely on and implicitly test third party libraries, while we could implicitly test and get a feel (feedback) on our own libraries, APIs, ...
All the issues which come with third party libraries
dependencies
maintenance
...
Background & Context
Having the tests within test/integration/sqlalchemy use SQLA primitives is fine because even our adjusted test cases there
should be looked at as part of SQLA and therefore meet their criteria.
Relying on SQLA tests fixtures and primitives within the test setup of our custom tests (test/integration/exasol) needs to be avoided though.
Examples
Replace/Remove SQLA test fixtures/classes e.g. sqlalchemy.testing.fixtures.TablesTest in test located in test/integration/exasol.
Summary
Rework the integration tests and setup to use exasol libraries (e.g.
pyexasol
orpytest-exasol
) for preparing the DBand setting up the tests written and maintained by exasol.
Details
Currently either
SQLA
,pyodbc
,turbodbc
or any combination of them is used to setup and prepare the test DB and it'scontents. This has at least two major flaws (shortcomings):
Chicken Egg Problem
While the core functionality of the exasol
SQLA dialect
is not working properly, it's very hard or impossibleto execute some or any tests with the appropriate DB and data setup.
It is not possible (without workarounds) to additionaly run integration tests which are not using the sqla test infrastructure.
* Test collection works differently (Tests won't get picked up)
* Test runs always need to provide db settings etc. to the sqla test plugin, otherwise the "pytest cli" will crash.
Eat Your Own Dog-food
We test and rely on and implicitly test third party libraries, while we could implicitly test and get a feel (feedback) on our own libraries, APIs, ...
All the issues which come with third party libraries
Background & Context
Having the tests within
test/integration/sqlalchemy
useSQLA
primitives is fine because even our adjusted test cases thereshould be looked at as part of
SQLA
and therefore meet their criteria.Relying on
SQLA
tests fixtures and primitives within the test setup of our custom tests (test/integration/exasol
) needs to be avoided though.Examples
Replace/Remove SQLA test fixtures/classes e.g.
sqlalchemy.testing.fixtures.TablesTest
in test located intest/integration/exasol
.References
maybe in the future
Task(s)
The text was updated successfully, but these errors were encountered: