Skip to content
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.

Sign up for GitHub

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

Jump to bottom

WIP: myTAP implementation of pgTAP runtests #50

Open
wants to merge 9 commits into
base: master
Choose a base branch
from
Open

WIP: myTAP implementation of pgTAP runtests #50

wants to merge 9 commits into from

Conversation

sq6jnx
Copy link
Contributor

@sq6jnx sq6jnx commented Oct 27, 2019

... as mentioned in #48. This branch is on top of #49.

sq6jnx
sq6jnx commented Oct 27, 2019
View reviewed changes
mytap-runtests.sql
END IF;

SET @call_sql = CONCAT('CALL ', db_, '.', proc_to_call, '()');
PREPARE call_sql FROM @call_sql;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is it safe to use "random" @ variables? Should we take care about potential conflicts (like rename this variable to @mytap__call_sql)?

sq6jnx
sq6jnx commented Oct 27, 2019
View reviewed changes
mytap-runtests.sql Outdated
DEALLOCATE PREPARE call_sql;
END LOOP;
CLOSE c;
end //
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fix case.

sq6jnx
sq6jnx commented Oct 27, 2019
View reviewed changes
mytap-runtests.sql Outdated Show resolved Hide resolved
sq6jnx
sq6jnx commented Oct 27, 2019
View reviewed changes
mytap-runtests.sql Outdated Show resolved Hide resolved
sq6jnx
sq6jnx commented Oct 27, 2019
View reviewed changes
tests/test-mytap-runtests.my

CALL tap.runtests(DATABASE());

CREATE TEMPORARY TABLE test_runtests2 LIKE test_runtests;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

LIKE base__test_runtests.

sq6jnx
sq6jnx commented Oct 27, 2019
View reviewed changes
mytap-runtests.sql
@@ -70,6 +70,7 @@ BEGIN
CALL _run_proc_by_prefix(db_, 'setup');
SET @call_sql = CONCAT('CALL ', db_, '.', test_to_call, '()');
PREPARE call_sql FROM @call_sql;
SELECT CONCAT("# ... ", test_to_call);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is it safe for i.e. my_prove? I was unable to test it.

sq6jnx
sq6jnx commented Oct 27, 2019
View reviewed changes
mytap-runtests.sql
@@ -46,9 +46,18 @@ BEGIN
ROUTINE_TYPE = 'PROCEDURE'
AND ROUTINE_SCHEMA = db_
AND ROUTINE_NAME LIKE 'test%'
ORDER BY ROUTINE_NAME;
ORDER BY
IF(random_seed IS NULL, NULL, RAND(random_seed))
Copy link
Contributor Author

Choose a reason for hiding this comment

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

There is a slight chance that shuffled order will be same as alphabetical one, but I don't think that's problem.

sq6jnx
sq6jnx commented Oct 27, 2019
View reviewed changes
mytap-runtests.sql Outdated Show resolved Hide resolved
@sq6jnx
Copy link
Contributor Author

sq6jnx commented Oct 27, 2019

Travis / my_prove said:

Test Summary Report
-------------------
tests/test-mytap-runtests.my  (Wstat: 0 Tests: 14 Failed: 2)
  Failed tests:  1, 1
  Parse errors: More than one plan found in TAP output
                Tests out of sequence.  Found (1) but expected (13)
                More than one plan found in TAP output
                Tests out of sequence.  Found (1) but expected (14)
                Bad plan.  You planned 12 tests but ran 14.
Files=22, Tests=1410,  6 wallclock secs ( 0.44 usr  0.08 sys +  0.10 cusr  0.10 csys =  0.72 CPU)
Result: FAIL
The command "my_prove -v -u root -h 127.0.0.1 tests/*.my" exited with 1.

The only possibility I see is to run all assertions in one plan.

@sq6jnx sq6jnx force-pushed the runtests branch 2 times, most recently from bb357d7 to 7fcfa05 Compare October 28, 2019 07:48
@sq6jnx
Copy link
Contributor Author

sq6jnx commented Oct 28, 2019 •
edited

Interesting case in build 31 for MySQL 5.7 (https://travis-ci.org/hepabolu/mytap/builds/603775539?utm_medium=notification&utm_source=github_status) -- it look there is a bug which arises when using constructions like SELECT tap.ok((<some SELECT with JOINS>), ...).

It's safer to use session variables.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
1 participant
@sq6jnx