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
Parameter drive tests #151
Comments
We can call it providing parameter values by iterating over sql statement using We can also accept a function which returns a cursor. Parameters should be mapped by name if the column aliases in the query correspond equally or by position if not. |
Does this need to support query input? The model I have in mind is;
With this you have the same capability, just without exposing SQL to the annotation. My concern is opening up avenue of issues where users want to persist test / results data to drive tests rather that keep tests isolated and UtPLSQL clean from data storage. |
I agree with @mathewbutler. I guess the better option is to preset all test data (like
No offense, guys, just thoughts out of my head :) |
We should look at something like this: |
I like the Functionality that the @MethodSource annotation in jUnit has. It provides a Stream of (multiple) parameters that are handed to the test executions. Like a rowtype in a way... |
I think there must be some kind of cursor as parameter ... so i can enter all i like - i hope you implemet this soon .... |
I think we could approach that problem with a new annotation to imitate an above --%parameterizedtest
--%valuesource{"Test"}
procedure testme(a_displayname in varchar2); result in : or --%parameterizedtest
--%valuesource{"Test,10"}
procedure testme(a_displayname in varchar2, a_beer_count in number); result in : or --%parameterizedtest
--%valuesource{"Test,10":"Test2,5"}
procedure testme(a_displayname in varchar2, a_beer_count in number); as alternative we could use a different annotation for multiple parameters so the code is more readable. e.g. --%parameterizedtest
--%valuesource{"Test,10"}
--%valuesource{"Test2,5"}
procedure testme(a_displayname in varchar2, a_beer_count in number); result in : The value source would be a colon separated inputs with list of coma separated values hat would have to be ordered in same way parameters in procedure each parameter entry as an annotation entry one below the other. Personally if we would to implement this I would suggest stick to basic datatypes. |
Actually I take it back. We could try to write a tests with |
I think it would be good to do a full review of what JUnit is proposing for parametrized tests and maybe check how other testing frameworks are solving this. In essence the key challenge is to come up with a good specification of annotations and parameters that will be relatively easy to use for average Oracle PL/SQL engineer. I think we should consider using DB tables for storing and reading parameters. |
There is an interesting extension to JUnit:
https://github.com/Pragmatists/JUnitParams
We could think of implementing something similar.
Here are examples of different ways to use it.
https://github.com/Pragmatists/JUnitParams/blob/master/src/test/java/junitparams/usage/SamplesOfUsageTest.java
The text was updated successfully, but these errors were encountered: