-
Notifications
You must be signed in to change notification settings - Fork 55
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
Introduce new module for shared interfaces #174
base: master
Are you sure you want to change the base?
Conversation
@akphi - Can we please include this in the next release of legend-engine ? Thanks |
Initial use cases for this module : (1) Mark new/wip apis for authn (2) Rename/simplify test classes/surefire configurations for tests such as Test_Relational_DbSpecific_Athena_UsingPureClientTestSuite, ExternalIntegration_TestConnectionAcquisitionWithFlowProvider_Databricks |
|
||
Used to indicate a test that can only be run on a CI/CD server because that test requires configuration (e.g. secrets) that are injected by the CI/CD server. | ||
*/ | ||
public interface RunUsingCICDServer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why we need this one? My worry is that extending this interface could lead executing wrong categories. Like, do we will ever enable RunUsingCICDServer or we will enable RunUsingGithubActions and/or RunUsingTeamCity?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not everyone uses Github or TeamCity. But we can always extract a base interface .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But if this is for the platform development, we should target what we use. Are aiming for people to use these generically? Even if that is the case, I will avoid extending this interface on the other two categories.
|
||
Used to indicate integration tests that test database functionality e.g. SQL generation, authentication etc | ||
*/ | ||
public interface DatabaseIntegrationTest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the difference between this and IntegrationTest? Why we need both?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One is more specific than the other ? For e.g for SQL tests, we want the surefire plugin to select a set of tests. I'm thinking of even more fine grained categories.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we annotate the Junit categoies as @experimentalapi :-D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the value for that? Like, where you think we will run Integration test cases, but not SQL or vice-versa?
We will have an increase likelihood of not running test cases if we make this a complicated set of toggles.
We should be looking at this from the "running any test" POV so that we can try to make as intelligent decisions as possible when scheduling. The closest you get to what is happening on the test, the harder will get to make further refactoring on how things are executed.
Introduce new module for shared interfaces