Skip to content

Feature/version check #26

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

Merged
merged 20 commits into from
Nov 10, 2017

Conversation

pesse
Copy link
Member

@pesse pesse commented Nov 8, 2017

Included Version-Check with database framework.
If Java-API is not compatible, TestRunner throws a DatabaseNotComptabileException.
Also included a simple Compability solution so API should be usable for 3.0.1, 3.0.2 and 3.0.3

viniciusam and others added 14 commits October 26, 2017 22:55
Adding orai18n to the dependencies
not sufficient though, we want to have a more specific check with fallback-mechanisms for some features
Also added some tests for getting Framework version and fixed error in getting it
As discussed in slack channel the goal is to have the most actual API
version be compatible with the major version of the framework.
API of a higher version should always be downwards compatible inside
the same major version.
had to restructure current code a bit to support different implementations of TestRunner calls
API should now be able to work for Framework-version 3.0.0 - 3.0.3
…error

Close reporters if any unexpected errors occurred while running tests
Copy link
Member

@viniciusam viniciusam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some classes are for internal use only and could be hidden from the API users by using the default/protected access modifiers, e.g: the TestRunnerOptions, Version and Statements.

What do you think?

*
* @return
*/
public String getVersionString()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not override toString?
If it's valid, couldn't you just return the origString?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed with the toString() method.
But I wouldn't return the origString because the class does some normalization, too, e.g. "v3.0.3" will be normalized to "3.0.3" or "version3.0.3" will also be normalized to "3.0.3". With that we are a bit more resilient against little changes.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually it might be even better to have the origString as toString-Method and getVersionString renamed to getNormalizedString

- TestRunnerStatement-Implementations are now hidden from public
- DatabaseNotCompatibleException now uses Version-objects instead of strings
- Version now contains a getNormalizedVersion()-method and it's
toString()-method returns the original version string
@viniciusam viniciusam merged commit 799792d into utPLSQL:feature/version_check Nov 10, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants