Skip to content

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

Closed
viniciusam opened this issue May 26, 2017 · 6 comments
Closed

Reporters API #8

viniciusam opened this issue May 26, 2017 · 6 comments
Labels

Comments

@viniciusam
Copy link
Member

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.

@jgebal
Copy link
Member

jgebal commented Aug 31, 2017

For now I would just say:
Client supports any custom reporter that does not need any parameters

This way we make that feature smaller and still of a great value.

@jgebal jgebal added the ready label Aug 31, 2017
@rponte
Copy link

rponte commented Nov 23, 2017

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 @Before and @After methods. Is it possible to do something like this already?

@jgebal
Copy link
Member

jgebal commented Nov 24, 2017

Hi @rponte
With utPLSQL all the framework logic resides in DB and java-api is just an API for the framework.

I think that the framework should be wrapping the tests and tests should not be referencing framework capabilities (like reporting).
I don't fully follow what you want to achieve.

Do you want to use JUnit tests with utPLSQL reporters?

@rponte
Copy link

rponte commented Nov 24, 2017

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?

@jgebal
Copy link
Member

jgebal commented Nov 24, 2017

This is something that is already available in DB API.
If you have a look at how our self-testing script used to work - this is what it does (in simplified form):

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.
This is because you may want to execute single run with multiple reporters, coverage should be started only once in that case.

@pesse
Copy link
Member

pesse commented Mar 20, 2018

closed by #45

@pesse pesse closed this as completed Mar 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants