Feature/update project documentation by jgebal · Pull Request #230 · utPLSQL/utPLSQL

jgebal · 2017-03-13T01:09:26Z

No description provided.

…uded in html docs. Updated project details Updated mkdocs.yml - new pages added Updated readme.md with new links

Added documentation for reporters and runnin-uni-tests Added documentation for ut_run-script

coveralls · 2017-03-13T01:14:31Z

Coverage remained the same at 77.033% when pulling 7ec3477 on jgebal:feature/update_project_documentation into 0c57f09 on utPLSQL:develop.

coveralls · 2017-03-13T06:07:06Z

Coverage remained the same at 77.0% when pulling d2ffa0d on jgebal:feature/update_project_documentation into 9096940 on utPLSQL:develop.

Pazus

I think we should add to the Installation guide a note that we create dbms_profiler tables if they dont already exists.

Pazus · 2017-03-13T04:35:58Z


+![3_steps](images/3_steps_to_run_utPLSQL.gif)
+
+Check out the sections on [annotations](userguide/annotations.md) and [expectations](userguide/expectations.md) to see how to define your tests  


I think we should provide lenks to other doc pages. Maybe womewhere in the beginning or at the end.

There is a bit of a conflict here.
The html doc generated with mkdocs contains all the pages and links as a menu.
I wanted to avoid duplication on the index page with what is defined in mkdocs.yml already.
I just pointed references to the things that are mentioned on the index.
We could however have the contents section (similar to the one in readme.md file).
The trouble is the duplication of sources.
Maybe we should generate docs from main project page and the readme.md should be the main page?
Anyway. That could be done as a further cleanup.

Pazus · 2017-03-13T04:36:41Z

- `be_greater_than`
- `be_greater_or_equal`
- `be_false`
+# Matchers


I think we should mention that most matchers have shortcuts such as to_equal

I didn't mention the shortcuts. We could add them as a separate section.
I think some shortcuts are not complete (not all data types have shortcuts to supported matchers). This is why they re not mentioned in the documentation.

Pazus · 2017-03-13T04:36:55Z

+
+Usage:
+```sql
+  ut.expect( a_actual {mulitple data-types} ).to_( be_between( a_lower_bound {mulitple data-types}, a_upper_bound {mulitple data-types}) );


check the whole page for it

Pazus · 2017-03-13T04:37:44Z

+
+Usage:
+```sql
+  ut.expect( a_actual buulean ).to_( be_false() );


type: boolean

Pazus · 2017-03-13T04:41:25Z

+
+If a matcher evaluated to NULL, then both `to_` and `not_to` will cause the expectation to report failure.
+
+Example:


I think examples should be moved to the beginning of the page. To be honest this a_actual {mulitple data-types} is a bit tricky from the first glance. Examples at the beginning are going to help to treat such notaion.

Pazus · 2017-03-13T04:44:47Z

+
+#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.


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

Pazus · 2017-03-13T04:46:00Z

+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


typo "using"

Pazus · 2017-03-13T04:48:10Z

+end;
+```
+
+Execute all tests from all packages that are on the _COM.MY_ORG.MY_PROJECT_ suitepath.


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.

Pazus · 2017-03-13T04:50:43Z

+select * from table(ut.run('hr.test_apply_bonus', ut_xunit_reporter()));
+```
+
+# ut_runner.run


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

Pazus · 2017-03-13T06:17:56Z

@@ -14,66 +14,213 @@ Expectation is a set of the expected value(s), actual values(s) and the matcher(

 Matcher is defining the comparison operation to be performed on expected and actual values. 


Do you think we can put the definition, matcher and example into a single table? I think it's going to be way shorter maybe even fit into a single screen

coveralls · 2017-03-21T01:18:57Z

Coverage remained the same at 75.533% when pulling 6acb912 on jgebal:feature/update_project_documentation into 0e4c308 on utPLSQL:develop.

jgebal added 5 commits March 12, 2017 16:07

Moving authors.md and CONTRIBUTING.md to docs/about, so they are incl…

412e002

…uded in html docs. Updated project details Updated mkdocs.yml - new pages added Updated readme.md with new links

Added images for reporters.

b1e6b97

Added documentation for reporters and runnin-uni-tests Added documentation for ut_run-script

Updated expectations documentation.

fccf763

Added missing page.

579c11c

Updated documentation.

7ec3477

jgebal added this to the version3 milestone Mar 13, 2017

jgebal added the in progress label Mar 13, 2017

Merge branch 'develop' into feature/update_project_documentation

d2ffa0d

Pazus suggested changes Mar 13, 2017

View reviewed changes

jgebal added 3 commits March 20, 2017 22:26

Merge branch 'develop' into feature/update_project_documentation

2b29c61

Addressed review comments.

a171f5f

Merge branch 'develop' into feature/update_project_documentation

6acb912

Pazus approved these changes Mar 21, 2017

View reviewed changes

Pazus merged commit 7a30f6c into utPLSQL:develop Mar 21, 2017

Pazus removed the in progress label Mar 21, 2017

jgebal deleted the feature/update_project_documentation branch March 22, 2017 00:31


		![3_steps](images/3_steps_to_run_utPLSQL.gif)

		Check out the sections on [annotations](userguide/annotations.md) and [expectations](userguide/expectations.md) to see how to define your tests


		If a matcher evaluated to NULL, then both `to_` and `not_to` will cause the expectation to report failure.

		Example:


		#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.

		@@ -14,66 +14,213 @@ Expectation is a set of the expected value(s), actual values(s) and the matcher(

		Matcher is defining the comparison operation to be performed on expected and actual values.

Conversation

jgebal commented Mar 13, 2017

Uh oh!

coveralls commented Mar 13, 2017

Uh oh!

coveralls commented Mar 13, 2017

Uh oh!

Pazus left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

coveralls commented Mar 21, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants