Feature/rework matcher #1076

lwasylow · 2020-06-07T14:21:10Z

Adding a matcher within_of.
Rework some of the compound expectation to use a pass a matcher to expectation to remove methods from ut_equal_compound.
Implements #77

jgebal · 2020-06-10T22:51:26Z

@lwasylow - sorry for not reviewing it yet.
I'll look at it this week.

docs/userguide/expectations.md

source/core/ut_utils.pkb

source/expectations/ut_expectation_base.tpb

source/expectations/ut_expectation_base.tps

source/expectations/ut_expectation_base.tpb

source/expectations/matchers/ut_equal.tpb

jgebal · 2020-06-13T19:44:01Z

source/expectations/matchers/ut_equal.tpb

+    l_result ut_equal := self;
+  begin
+    l_result.options.exclude.add_items(a_items);
+    l_result.expectation.to_(l_result );


all calls to: l_result.expecatation in this type are assuming that the expectation attribute is set.

Given the number of places this is called, it would be good to delegate exception handling to a helper procedure.

@lwasylow
I don't really remember why this change was done.
I think it's part of some clean-up operation but not really part of new matcher. Is your memory any better than mine?

@jgebal

Went back to old conversations on slack from may 27th 2020 and found this:

To not duplicate old methods from matchers we can change behaviour.
UT_MATCHER is additional attribute of expectation which is set when function is called.
Procedure TO_EQUAL in UT_EXPECTATION works the same.

Yeah. I've found it. But after 2 years I can't even understand what I had in mind.
I'll put the original (polish) version here, just in case, as the free version of SLACK that we use purges messages history.

Propozycja:
Żeby nie duplikować wszystkich metod z matcherów w ut_Expectation można zmienić to zachowanie w następujący sposób:
ut_matcher a teraz dodatkowy atrybut expectation który jest ustawiany gdy wołana jest funcja.
Procedura to_equal w ut_Expectation działa jak dotychczas - raportuje expecattaion
Funkcja to_equal w ut_Expecattion_compound :
ustawia wartość pola expectation w przekazanym matcher na wartość self
zwraca matcher, tak żeby metchod chaining teraz już używał metod matchera (dzięki temu nie trzeba już duplikować dodatkowych metod w ut_expectation
Matcher może odwołać się teraz do expectation z którego został wywołany.
W procedurze matchera (ostatnia metoda w łańcuchu) self.expecation is null matcher nie woła expecataion, w innym wypadku procedury matcher wołaję metodę to_ przekazując self
W ten sposób składnia:
ut.expect(...).to_( equal(...).incude(...) ) sprawia, że:
matcher nie woła expectation, bo expectation nie jest ustawione w matcher
matcher jest przekazany do expectation i expectation wykonuje sprawdzenie wartości i raportuje
Składnia:
ut.expect(...).to_equal(...).include sprawia że:
to_equal ustawia self jako expectation w matcherze, zwraca matcher i dokonuje się metchod chaining
include wywoływane jest na matcherze i poniewarz jest to procedura i pole expectation jest ustawione, matcher woła metodę ecpectation.to_ przekazując self jako arcument
Powinno działać, ale jest 2 w nocy więc mogę majaczyć

Added synonym and grant for matcher Reworked expectation to work fine with syntax `to_( matcher() )` for to_be_within. TODO - add tests for other matchers with `to_( matcher )` and `not_to( matcher )` syntax

…tPLSQL into feature/rework_matcher

Reorganized code so that `be_within_pct` is only supported for `number` Added tests for non-supported syntax

No tests

sonarqubecloud · 2020-06-28T11:42:14Z

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities (and 1 Security Hotspot to review)
18 Code Smells

89.2% Coverage
0.0% Duplication

pesse · 2020-11-12T17:04:51Z

What's missing here? Maybe I can help

Added sql-injection check.

jgebal · 2022-01-29T23:07:05Z

While running the feature tests locally just now, I have noticed a pitfall of using interval datatype as a time distance.
The below block fails with exceptions:

set serverout on;
begin
  ut.expect(date '2022-01-30').to_be_within(INTERVAL '1'  MONTH).of_(date '2022-01-30');
end;
/
begin
  ut.expect(date '2022-05-31').to_be_within(INTERVAL '1'  MONTH).of_(date '2022-05-31');
end;
/

begin
  ut.expect(date '2022-01-30').to_be_within(INTERVAL '1'  MONTH).of_(date '2022-01-30');
end;
Error report -
ORA-01839: date not valid for month specified
ORA-06512: at line 11
ORA-06512: at "UT3.UT_BE_WITHIN_HELPER", line 24
ORA-06512: at "UT3.UT_BE_WITHIN", line 114
ORA-06512: at "UT3.UT_EXPECTATION_BASE", line 26
ORA-06512: at "UT3.UT_BE_WITHIN", line 44
ORA-06512: at line 2
01839. 00000 -  "date not valid for month specified"
*Cause:    
*Action:

Error starting at line : 6 in command -
begin
  ut.expect(date '2022-05-31').to_be_within(INTERVAL '1'  MONTH).of_(date '2022-05-31');
end;
Error report -
ORA-01839: date not valid for month specified
ORA-06512: at line 3
ORA-06512: at "UT3.UT_BE_WITHIN_HELPER", line 24
ORA-06512: at "UT3.UT_BE_WITHIN", line 114
ORA-06512: at "UT3.UT_EXPECTATION_BASE", line 26
ORA-06512: at "UT3.UT_BE_WITHIN", line 44
ORA-06512: at line 2
01839. 00000 -  "date not valid for month specified"
*Cause:    
*Action:

This is because:
January 30 + Interval '1' month, according to Interval maths is February 30th 😞
and
May 31st + Inter

val '1' month, according to Interval maths is June 31st

So, we would really need to rethink the maths and meaning of + 1 month to be more like add_months logic which assumes that if the day of month falls beyond last day of a month, it means it should be last day of a month.
Example:

select add_months(date '2022-05-31',1) from dual;
2022-06-30 12:00:00 AM

It seems that only the interval month logic suffers from that problem.

jgebal · 2022-01-29T23:08:35Z

Well. interval year can also suffer from that problem on leap years.
https://stackoverflow.com/questions/35695175/oracle-db-ora-01839-date-not-valid-for-month-specified-29-02-2016-leap-year

mathewbutler · 2022-01-30T08:29:20Z

The stack overflow link references this spec:

http://www.inf.fu-berlin.de/lehre/SS05/19517-V/FolienEtc/sql-foundation-aug94.pdf

Table 11— “Valid values for fields in datetime items” (page 130) states:

DAY - “ Within the range 1 to 31, but further constrained by the value of MONTH and YEAR fields, according to the rules for well-formed dates in the Gregorian calendar.”

This suggests that valid Gregorian calendar days should be the result.

I’d this behaviour of INTERVAL types an Oracle bug?

lwasylow · 2022-01-30T12:25:12Z

Well. interval year can also suffer from that problem on leap years. https://stackoverflow.com/questions/35695175/oracle-db-ora-01839-date-not-valid-for-month-specified-29-02-2016-leap-year

I think we can work this around as we already have function to extract string from interval. I reckon we can try go this route to translate interval into add_months etc.

mathewbutler · 2022-01-30T14:24:57Z

The stack overflow link references this spec:

http://www.inf.fu-berlin.de/lehre/SS05/19517-V/FolienEtc/sql-foundation-aug94.pdf

Table 11— “Valid values for fields in datetime items” (page 130) states:

DAY - “ Within the range 1 to 31, but further constrained by the value of MONTH and YEAR fields, according to the rules for well-formed dates in the Gregorian calendar.”

This suggests that valid Gregorian calendar days should be the result.

I’d this behaviour of INTERVAL types an Oracle bug?

More digging and Oracle state this not a bug - just the way INTERVAL works. There’s an asktom from 2005 - Mr Kyte covers it all:

https://asktom.oracle.com/pls/apex/f?p=100:11:0::::p11_question_id:1157035034361

jgebal · 2022-01-30T20:48:49Z

I think I've found a solution that would still rely on internal oracle logic related to intervals.
We currently use the below pseudo-code

declare
  l_result boolean;
begin
  l_result := 
    a_actual  between (a_expected - a_distance) and (a_expected + a_distance);
end;

The above results in problems when we calculate: (a_expected -/+ a_distance) for a_distance expressed as YM Interval when the calculation would result in invalid day of month like below:

select (timestamp '2022-01-30 14:45:56.123456'  + interval '0-1' year to month) from dual;

However we can express the same intent with a different formula:

declare
  l_result boolean;
begin
  l_result := ( least( a_actual, a_expected ) - greatest(a_actual, a_expected) ) year to month <= a_distance;
end;

That way, we avoid the problems with invalid dates rather than adding/subtracting interval to date, we calculate YM distance between dates and then compare it to expected max distance.

For date datatype of expected & actual this would look like below:

declare
  l_result boolean;
begin
  l_result := ( cast(least( a_actual, a_expected ) as timestamp) - cast( greatest(a_actual, a_expected) as timestamp) ) year to month <= a_distance;
end;

…month Improved error handling for null values and incompatible datatypes Improved handling of negative dates (BC) Improved reporting of interval text value Improved datatypes to handle large&small precissions for timestamps

jgebal · 2022-01-30T23:52:43Z

I have implemented required fixes.
@lwasylow @mathewbutler - would you mind having a look at latest commit?

jgebal · 2022-01-30T23:57:25Z

TODO - review readme and documentation update to assure that the matcher is well explained along with it's limitations and behaviour to make sure there is no confusion when folks will use it.

Added human-readable reporting of tests run-time into `ut_documentation_reporter`.

…rk for Pull Requests

sonarqubecloud · 2022-01-31T22:36:04Z

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

94.5% Coverage
0.0% Duplication

jgebal · 2022-01-31T23:23:05Z

Question:
Should the to_be_within matcher allow for comparison of

timestamp vs timestamp with time zone
timestamp vs timestamp with local time zone
date vs timestamp
etc.

That is, should we relax the strict datatype check that is present for the to_equal and allow for more relaxed check?
I think now is the time for this discussion before we merge and release this new matcher.

…n expected (not only smaller). Updated documentation.

jgebal · 2022-02-02T23:37:47Z

I have fixed 2 issues with pct matcher:

divisor=0 on expected = 0
matcher worked only one way.
ut.expect(99).to_be_within_pct(1).of_(100) was giving SUCCESS
ut.expect(101).to_be_within_pct(1).of_(100) was giving FAILURE

With the change introduced now we will have:

begin
  ut3_develop.ut.expect(99).to_be_within_pct(1).of_(100);
  ut3_develop.ut.expect(101).to_be_within_pct(1).of_(100);
  ut3_develop.ut.expect(99).to_be_within_pct(1).of_(100);
  ut3_develop.ut.expect(101).to_be_within_pct(1).of_(100);
  ut3_develop.ut.expect(0).to_be_within_pct(1).of_(0);
  ut3_develop.ut.expect(0).to_be_within_pct(100).of_(1);
  ut3_develop.ut.expect( 1.0001 ).to_be_within_pct( -0.01 ).of_(1);
end;
/

SUCCESS
  Actual: 99 (number) was expected to be within 1 % of 100 (number)
SUCCESS
  Actual: 101 (number) was expected to be within 1 % of 100 (number)
SUCCESS
  Actual: 99 (number) was expected to be within 1 % of 100 (number)
SUCCESS
  Actual: 101 (number) was expected to be within 1 % of 100 (number)
SUCCESS
  Actual: 0 (number) was expected to be within 1 % of 0 (number)
SUCCESS
  Actual: 0 (number) was expected to be within 100 % of 1 (number)
SUCCESS
  Actual: 1.0001 (number) was expected to be within -.01 % of 1 (number)

@lwasylow

…nteger and cannot be used to express a decimal distace value. Improved tests coverage for various scenarios.

sonarqubecloud · 2022-02-02T23:45:48Z

Please retry analysis of this Pull-Request directly on SonarCloud.

sonarqubecloud · 2022-02-02T23:45:54Z

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

95.9% Coverage
0.0% Duplication

lwasylow added 8 commits June 1, 2020 21:58

Initial checkin

48abf1a

added expectation

7041912

Adding more methods

13d86b6

Adding contain and not contain

caeeb30

Adding code and tests,.

8ff4f6b

Fixingtoo long names

89cb0bc

fixing issue

a5481ac

Update documentation and tests

9ee0e75

lwasylow requested a review from jgebal June 7, 2020 14:30

jgebal requested changes Jun 13, 2020

View reviewed changes

lwasylow and others added 17 commits June 14, 2020 20:02

First code corrections

a660208

Resolving another comment

ada1ea4

Updating issues

fe1b0cb

Update tble

013db74

Separated into two different matchers

b5c73b4

Added synonym and grant for matcher Reworked expectation to work fine with syntax `to_( matcher() )` for to_be_within. TODO - add tests for other matchers with `to_( matcher )` and `not_to( matcher )` syntax

CHECKPOINT

2e721da

Merge branch 'feature/rework_matcher' of https://github.com/utPLSQL/u…

fbc0f26

…tPLSQL into feature/rework_matcher

Update uninstall

f182430

Update progress

e3fb2d7

Making code a bit more readable

322e0a1

Added tests for be_within_pct

ff15596

Reorganized code so that `be_within_pct` is only supported for `number` Added tests for non-supported syntax

Fixed test issue

3cae9a2

Fixed stacktrace for failed expectations on chained matchers.

22549db

Update timestamps

1d771a5

No tests

Fixed and simplified matcher

363c333

Fixed native dynamic SQL types compatibility for 11g

0ea8925

Fixed native dynamic SQL types compatibility for 11g

7c01afb

jgebal added 2 commits January 28, 2022 23:23

Removing reference to ut3_develop schema.

5e2642a

Added sql-injection check.

Relaxed sql-injection check to work with 11g2

ed06e33

jgebal added this to the 3.1.12 milestone Jan 29, 2022

jgebal force-pushed the feature/rework_matcher branch from 7c121ab to 4e0c703 Compare January 31, 2022 21:30

Improving code coverage.

86e84c8

jgebal force-pushed the feature/rework_matcher branch from 4e0c703 to 86e84c8 Compare January 31, 2022 21:40

jgebal added 2 commits February 1, 2022 00:14

Improved test stability.

718ac0d

Added human-readable reporting of tests run-time into `ut_documentation_reporter`.

Fixing build process to build using develop branch as testing framewo…

6dbef20

…rk for Pull Requests

Improving test coverage.

25b55b4

jgebal added 2 commits February 1, 2022 01:58

Improving matcher documentation

5b5a5c0

Added tests for 0 value of actual and expected and actual greater tha…

7fec0f9

…n expected (not only smaller). Updated documentation.

Fixed issues with precission of distance. NATURAL is a subtype of i…

fd7ef9c

…nteger and cannot be used to express a decimal distace value. Improved tests coverage for various scenarios.

jgebal approved these changes Feb 2, 2022

View reviewed changes

lwasylow linked an issue Feb 3, 2022 that may be closed by this pull request

Add be_within 'fuzzy' matcher #77

Closed

jgebal merged commit b0a2aab into develop Feb 4, 2022

jgebal deleted the feature/rework_matcher branch February 4, 2022 19:21

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feature/rework matcher #1076

Feature/rework matcher #1076

lwasylow commented Jun 7, 2020 •

edited

Loading

jgebal commented Jun 10, 2020

jgebal Jun 13, 2020

jgebal Jun 13, 2020

jgebal Jan 31, 2022

lwasylow Jan 31, 2022

jgebal Jan 31, 2022

sonarqubecloud bot commented Jun 28, 2020

pesse commented Nov 12, 2020

jgebal commented Jan 29, 2022

jgebal commented Jan 29, 2022

mathewbutler commented Jan 30, 2022

lwasylow commented Jan 30, 2022

mathewbutler commented Jan 30, 2022

jgebal commented Jan 30, 2022

jgebal commented Jan 30, 2022

jgebal commented Jan 30, 2022

sonarqubecloud bot commented Jan 31, 2022

jgebal commented Jan 31, 2022

jgebal commented Feb 2, 2022

sonarqubecloud bot commented Feb 2, 2022

sonarqubecloud bot commented Feb 2, 2022

Feature/rework matcher #1076

Feature/rework matcher #1076

Conversation

lwasylow commented Jun 7, 2020 • edited Loading

jgebal commented Jun 10, 2020

jgebal Jun 13, 2020

Choose a reason for hiding this comment

jgebal Jun 13, 2020

Choose a reason for hiding this comment

jgebal Jan 31, 2022

Choose a reason for hiding this comment

lwasylow Jan 31, 2022

Choose a reason for hiding this comment

jgebal Jan 31, 2022

Choose a reason for hiding this comment

sonarqubecloud bot commented Jun 28, 2020

pesse commented Nov 12, 2020

jgebal commented Jan 29, 2022

jgebal commented Jan 29, 2022

mathewbutler commented Jan 30, 2022

lwasylow commented Jan 30, 2022

mathewbutler commented Jan 30, 2022

jgebal commented Jan 30, 2022

jgebal commented Jan 30, 2022

jgebal commented Jan 30, 2022

sonarqubecloud bot commented Jan 31, 2022

jgebal commented Jan 31, 2022

jgebal commented Feb 2, 2022

sonarqubecloud bot commented Feb 2, 2022

sonarqubecloud bot commented Feb 2, 2022

lwasylow commented Jun 7, 2020 •

edited

Loading