-
Notifications
You must be signed in to change notification settings - Fork 5
Reporters API #8
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
Comments
For now I would just say: This way we make that feature smaller and still of a great value. |
Hi guys, you have made a great job! Congrats! But I'd like to know if I can use a kind of Reporter API, if there is one, so that I can gather all results from utPLSQL's reporter. Nowadays I'm testing all PLSQL code through a test suite written in Java with jUnit, so I'm looking for an API like this: @Test
public void shouldFindAProductByName() {
reporterApi.startGathering(); // starts reporter to gather code coverage
Product p = productDao.findByName("iPad"); // exercises PLSQL code here
assertEquals(2020, p.getId());
reporterApi.endGathering(); // ends reporter
System.out.println(reporterApi.printResults()); // shows results later or when needed
} Of course this could be put into a jUnit Rule or even in |
Hi @rponte I think that the framework should be wrapping the tests and tests should not be referencing framework capabilities (like reporting). Do you want to use JUnit tests with utPLSQL reporters? |
Hi @jgebal, Yeah! Just to be clear, this is exactly what I want: generate reports using utPLSQL from my jUnit tests. The idea of a code coverage reporter is gathering the coverage of a code exercised in specific context/session/scenario. In the case of utPSQL reporter, it could gather the code coverage of procedures executed in a session, regardless of whether this procedure was executed by utPLSQL, or jUnit+JDBC or even by an anonymous block via SQL Developer IDE. What I'm looking for and expecting from utPLSQL is a reporter API like this: declare
l_html_report varchar2(4000);
ut_reporter Ut_Reporter_API;
begin
ut_reporter := new Ut_Reporter_API();
ut_reporter.startGathering(config=>'...'); // starts reporter to gather code coverage
my_pkg.do_something('foo'); // exercises PLSQL code here
ut_reporter.endGathering(); // ends reporter
l_html_report := ut_reporter.get_result(type => 'html'); // generates results
end; Do you understand? I know I need to install utPLSQL in my database, there's no issue with this. But I'd like to use only its Reporter API from any session. If there's one way to do that with utPLSQL and you guide me through it I can do a pull request improving this Java API. What do you think? |
This is something that is already available in DB API. begin
ut_coverage.coverage_start();
end;
/
------------------------------
-----your stuff goes here
------------------------------
prompt Generating coverage data to reporter outputs
var html_reporter_id varchar2(32);
declare
v_reporter ut_reporter_base;
begin
v_reporter := ut_coverage_html_reporter();
:html_reporter_id := v_reporter.reporter_id;
--generate coverage report
v_reporter.after_calling_run(null);
end;
/
set termout on
prompt Spooling outcomes to coverage.html
set termout off
spool coverage.html
exec ut_output_buffer.lines_to_dbms_output(:html_reporter_id);
-- or
--select * from table(ut_output_buffer.get_lines(:html_reporter_id));
spool off
exit We used this approach for self-testing and reporting code coverage for a while (until we started using client). I would like to avoid putting this API into Java if it is only to satisfy external testing. In utPLSQL, it's not the reporter that starts the coverage, it's the RUN. |
closed by #45 |
Currently every reporter has its own class to be used on TestRunner. Maybe would be better to have just one BasicReporter type, with a reporter name parameter.
The only reporter that has extra parameter is the ut_coverage_html_reporter, but the user can create his own reporters. We would need a CustomReporter class which supports extra params, or extend the BasicReporter to support it.
The text was updated successfully, but these errors were encountered: