Skip to content
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Added images for reporters.
Added documentation for reporters and runnin-uni-tests
Added documentation for ut_run-script
  • Loading branch information
jgebal committed Mar 12, 2017
commit b1e6b9781739c2292f7595531138bb6114f2a482
Binary file added docs/userguide/images/documentation_reporter.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/userguide/images/xunit_reporter_jenkins.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
96 changes: 94 additions & 2 deletions docs/userguide/reporters.md
Original file line number Diff line number Diff line change
@@ -1,2 +1,94 @@
#Unit Test reporters
TODO
utPLSQL provides the following reporting formats.

#Documentation reporter

The `ut_documentation_reporter` is the default reporting format used by the framework.
It provides a human readable test results.

To invoke tests with documentation reporter use one of following calls from sql console (SQLPlus)

`exec ut.run();`

`exec ut.run(ut_documentation_reporter());`

You may also invoke unit tests directly from command line by calling.

`sqlplus /nolog @ut_run %user%/%pass%@%dbsid%`

Invoking tests from command line tool `ut_run.sql` allows you to track progress of test execution.
In that case, the documentation reporter will provide information about each test that was executed as soon as it's execution finishes.
For more details on using the `ut_run.sql` script look into [ut_run.sql](ut_run-script.md) documentation.

The `ut_documentation_reporter` doesn't accept any arguments.

Example outputs from documentation reporter.

![doc_reporter_outputs](images/documentation_reporter.png)

The documentation report provides the following information.
- Test suite name or test package name (nested with suitepath if suitepath is used)
- Test description name or test procedure name
- Information about test failing `(FAILED - n)`
- Information about disabled test `(IGNORED)`
- List of all errors and failures
- Summary with total number of tests, number of tests with status and timing for the execution


##Color output from documentation reporter

When invoking tests with documentation reporter and your command line supports ANSICONSOLE (default on Unix), you can obtain the coloured outputs from the documentation reporter.

To invoke tests with documentation reporter in color mode use one of following calls.

`exec ut.run(a_color_console=>true);`

`exec ut.run(ut_documentation_reporter(), a_color_console=>true);`

Example outputs from documentation reporter.

![doc_reporter_outputs](images/documentation_reporter_color.png)


#XUnit reporter

Most of continuous integration servers (like Jenkins) are capable of consuming unit test execution results in [XUnit/JUnit](https://en.wikipedia.org/wiki/XUnit) format.
The `ut_xunit_reporter` is producing outcomes as XUnit-compatible XML unit test report, that can be used by CI servers to display their custom reports and provide metrics (like tests execution trends).

Invocation of tests with XUnit reporter.

`exec ut.run(ut_xunit_reporter());`

The `ut_xunit_reporter` doesn't accept any arguments.

Example of xunit report integrated with [Jenkins CI](https://jenkins.io/)

![xunit_reporter_outputs](images/xunit_reporter_jenkins.png)

Example of failure report details

![xunit_reporter_outputs](images/xunit_reporter_jenkins_errors.png)


#Teamcity reporter

[Teamcity](https://www.jetbrains.com/teamcity/) is a CI server by Jetbrains. The CI has it's own format of reporting that allows tracking of progress of a CI step/task as it executes.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I'd say it has the own format additionaly to the stadard ones like xUnit/jUnit

The format developed by Jetbrains is supported by utPLSQL with `ut_teamcity_reporter`.

Invocation of tests with Teamcity reporter.

`exec ut.run(ut_teamcity_reporter());`

The `ut_teamcity_reporter` doesn't accept any arguments.

Example of unit test report from Teamcity CI server.

![xunit_reporter_outputs](images/teamcity_report_example.png)

Example of failure report details

![xunit_reporter_outputs](images/teamcity_report_example_errors.png)


# Coverage reporters

utPLSQL comes with a set of build-in coverage reporters. Have a look into the [coverage documentation](coverage.md) to learn more about them.
107 changes: 105 additions & 2 deletions docs/userguide/running-unit-tests.md
Original file line number Diff line number Diff line change
@@ -1,2 +1,105 @@
#Running unit tests
TODO
utPLSQL framework provides two main entry points to run unit tests from within database:
- `ut.run` procedures and functions
- `ut_runner.run` procedures

Those two entry points differ in purpose and behavior.

# ut.run
Package `ut` contains overloaded procedures and functions `run`.
The `run` API is designed to be called directly by developer, when using IDE/SQL console to execute unit tests.
The main benefit of using this API is it's simplicity.
One-line call is enough to execute a set of tests form one or multiple schemes.

The **procedures** execute specified tests and produces outputs to DBMS_OUTPUT suing specified reporter
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

typo "using"

The **functions** can only be used in SELECT statements. They execute specified tests and produce outputs as a pipelined data stream to be consumed by select satement.

## ut.run procedures

Examples:
```sql
alter session set current_schema=hr;
begin
ut.run();
end;
```
Execute all tests in current schema (_HR_).

```sql
begin
ut.run('HR');
end;
```
Execute all tests in specified schema (_HR_).

```sql
begin
ut.run('hr.test_apply_bonus');
end;
```
Execute all tests from package _HR.TEST_APPLY_BONUS_.

```sql
begin
ut.run('hr.test_apply_bonus.bonus_cannot_be_negative');
end;
```
Execute single test procedure _HR.TEST_APPLY_BONUS.BONUS_CANNOT_BE_NEGATIVE_.

```sql
begin
ut.run(ut_varcahr2_list('hr.test_apply_bonus','cust'));
end;
```
Execute all tests from package _HR.TEST_APPLY_BONUS_ and all tests from schema _CUST_.
Using a list of things to execute allows you to execute a fine-grained set of tests.

```sql
begin
ut.run('hr:com.my_org.my_project');
end;
```

Execute all tests from all packages that are on the _COM.MY_ORG.MY_PROJECT_ suitepath.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I propose to restructure the doc a bit. I believe we should treat suitepath as the prefered way to configure runs, so the examples should first demonstrate that approach. Calling by a package name is a convinient addition.

Check the [annotations documentation](annotations.md) to find out about suitepaths and how they can be used to group test packages.

**Note:**
`ut_documentation_reporter` is default reporter for all API's defined for running unit tests.

The `ut.run` procedures and functions accept `a_reporter` attribute that defines the reporter to be used in the run.
You can execute any set of tests with any of the predefined reporters.

```sql
begin
ut.run('hr.test_apply_bonus', ut_xunit_reporter());
end;
```
Execute all tests from package _HR.TEST_APPLY_BONUS_ and provide outputs to DBMS_OUTPUT using the XUnit reporter.

For details on build-in reporters look at [reporters documentation](reporters.md).

## ut.run functions

The `ut.run` functions provide exactly the same functionality as the procedures. You may use the same sets of parameters with both functions and procedures. The only difference is the output of the results.
Functions provide outputs as pipelined stream and therefore need to be executed as select statements.

Example.
```sql
select * from table(ut.run('hr.test_apply_bonus', ut_xunit_reporter()));
```

# ut_runner.run
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I think you should mention again that the easiest way to invoke ut_runner is to call it with ut_run.sql


The `ut_runner` provides API for integrating utPLSQL with other products. Maven, Jenkins, SQL Develper, PL/SQL Developer, TOAD and others can leverage this API to call utPLSQL.

The main difference as compared to `ut.run` API is that the `ut_runner.run` does not provide outputs.

`ut_runner.run` accepts multiple reporters. Each reporter produces outputs into a separate output (uniquely identified by output_id).
Outputs of multiple reporters can be consumed in parallel. This allows for live reporting of test execution progress with threads and several database sessions.

The concept is pretty simple.

- in main thread (session), define the reporters to be used. Each reporter has it's output_id and so you need to extract and store those output_id's.
- as a separate thread, start the `ut_runner.run` and pass reporters with previously defined output_id's
- for each reporter start a separate thread and read outputs from `ut_output_buffer.get_lines` table function by providing the output_id defined in the main thread.


52 changes: 52 additions & 0 deletions docs/userguide/ut_run-script.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
The `ut_run.sql` script is designed to allow invocation of utPLSQL with multiple reporters.
It allows saving of outcomes into multiple output files.
It also facilitates displaying on screen unit test results while the execution is still ongoing.
Current limit of script parameters is 39

#Scrip invocation
ut_run.sql user/password@database [-p=(ut_path|ut_paths)] [-c] [-f=format [-o=output] [-s] ...]

#Parameters
```
user - username to connect as
password - password of the user
database - database to connect to
-p=ut_path(s)- A path or a comma separated list of paths to unit test to be executed.
The path can be in one of the following formats:
schema[.package[.procedure]]
schema:suite[.suite[.suite][...]][.procedure]
Both formats can be mixed in the comma separated list.
If only schema is provided, then all suites owner by that schema (user) are executed.
If -p is omitted, the current schema is used.
-f=format - A reporter to be used for reporting.
Available options:
-f=ut_documentation_reporter
A textual pretty-print of unit test results (usually use for console output)
-f=ut_teamcity_reporter
A teamcity Unit Test reporter, that can be used to visualize progress of test execution as the job progresses.
-f=ut_xunit_reporter
A XUnit xml format (as defined at: http://stackoverflow.com/a/9691131 and at https://gist.github.com/kuzuha/232902acab1344d6b578)
Usually used by Continuous Integration servers like Jenkins/Hudson or Teamcity to display test results.
If no -f option is provided, the ut_documentation_reporter will be used.

-o=output - file name to save the output provided by the reporter.
If defined, the output is not displayed on screen by default. This can be changed with the -s parameter.
If not defined, then output will be displayed on screen, even if the parameter -s is not specified.
If more than one -o parameter is specified for one -f parameter, the last one is taken into consideration.
-s - Forces putting output to to screen for a given -f parameter.
-c - If specified, enables printing of test results in colors as defined by ANSICONSOLE standards
```

Parameters -f, -o, -s are correlated. That is parameters -o and -s are defining outputs for -f.

Examples of invocation using sqlplus from command line:

`sqlplus /nolog @ut_run hr/hr@xe -p=hr_test -f=ut_documentation_reporter -o=run.log -s -f=ut_teamcity_reporter -o=teamcity.xml`

All Unit tests from schema/package "hr_test" will be be invoked with two reporters:
- ut_documentation_reporter - will output to screen and save it's output to file "run.log"
- ut_teamcity_reporter - will save it's output to file "teamcity.xml"

`sqlplus /nolog @ut_run hr/hr@xe`

All Unit tests from schema "hr" will be be invoked with ut_documentation_reporter as a format and the results will be printed to screen
28 changes: 18 additions & 10 deletions readme.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,15 +17,18 @@ utPLSQL version 3 is a complete rewrite of utPLSQL v2 from scratch.
Version 2 still supports older versions of Oracle that are no longer available.
The community that had developed on GitHub, decided that a new internal architecture was needed, from that version 3 was born.

We welcome new developers to join our community and contribute to the utPLSQL project.
# Introduction
utPLSQL is a Unit Testing framework for Oracle PL/SQL and SQL.
The framework follows industry standards and best patterns of modern Unit Testing frameworks like [JUnit](http://junit.org/junit4/) and [RSpec](http://rspec.info/)


Primary features:
- Support for all basic scalar data-types
# Primary features
- Support for all basic scalar data-types except ROWID and RAW
- Support for User Defined Object Types and Collections
- Support for native cursors both strong and weak
- Data-type aware testing
- [Annotations](docs/userguide/annotations.md) based test definitions
- Extensible [matchers](docs/userguide/expectations.md)
- Data-type aware testing - number 1 is not equal to string '1'
- [Annotations](docs/userguide/annotations.md) are used to define and configure tests
- Extensible [expectations](docs/userguide/expectations.md)
- Extensible reporting formats
- Extensible output providers
- Support for multi-reporting
Expand All @@ -43,6 +46,15 @@ __Download__

Published releases are available for download on the [utPLSQL GitHub Releases Page.](https://github.com/utPLSQL/utPLSQL/releases)

# Contributing to the project

We welcome new developers to join our community and contribute to the utPLSQL project.
If you are interested in helping please read our [guide to contributing](docs/about/CONTRIBUTING.md)
The best place to start is to read the documentation and get familiar existing with code base.
A [slack chat](https://utplsql.slack.com/) is the place to go isf you want to talk with team members.
To sign up to the chat use [this link](http://utplsql-slack-invite.herokuapp.com/)


[__Authors__](docs/about/authors.md)

__Version 2 to Version 3 Comparison__
Expand Down Expand Up @@ -195,10 +207,6 @@ c:\my_work\>sqlplus /nolog @ut_run hr/hr@xe
Will run all the suites in the current schema (hr) and provide documentation report into screen.
Invoking this script will show the progress after each test.

# Contributing to the project

Community help on is always appreciated, if your interested in helping please read our [guide to contributing](docs/about/CONTRIBUTING.md)

__Project Directories__

* .travis - contains files needed for travis-ci integration
Expand Down