[Maria-developers] MDEV-30: "mtr extensions for storage engine testing" review
Hi Serg! As promised, I read through your MDEV-30, "mtr extensions for storage engine testing". Generally I think it looks good and reasonable. Here are a few comments: - --record should have options so that it can generate .rdiff or .COMBI.result. So one could say eg. ./mtr --record=rdiff <some test> to produce <whatever>.rdiff. It's not entirely trivial what the exact syntax should be due to the complicated structure of result file names... - Windows (the usual problem child :-( ) has no native `patch` tool. Will we require it to be installed, or will we gracefully skip tests that need it if no patch is available? - About the "options" at the end about file names wrt. suites: I did not fully understand - but it seems important that whatever is done, existing lots of test cases from Oracle/MySQL can be used without having to rewrite their --source statements. Will this be the case? Hope this helps, - Kristian.
Hi, Kristian! On Jan 23, Kristian Nielsen wrote:
Hi Serg!
As promised, I read through your MDEV-30, "mtr extensions for storage engine testing".
Generally I think it looks good and reasonable. Here are a few comments:
- --record should have options so that it can generate .rdiff or .COMBI.result. So one could say eg. ./mtr --record=rdiff <some test> to produce <whatever>.rdiff. It's not entirely trivial what the exact syntax should be due to the complicated structure of result file names...
I've thought of that problem. My idea was that one could simply diff .reject and .result file to get a proper .rdiff file. Or something like that. I have a whole pbxt suite to play with and to see what a good solution could be.
- Windows (the usual problem child :-( ) has no native `patch` tool. Will we require it to be installed, or will we gracefully skip tests that need it if no patch is available?
Gracefully skip. I've added this to the task description this morning :)
- About the "options" at the end about file names wrt. suites: I did not fully understand - but it seems important that whatever is done, existing lots of test cases from Oracle/MySQL can be used without having to rewrite their --source statements. Will this be the case?
Of course. Currently we have, for example, rpl_mixed_implicit_commit_binlog.test rpl_row_implicit_commit_binlog.test rpl_stm_implicit_commit_binlog.test and they all do exactly the same: --source include/have_binlog_format_statement.inc --source extra/rpl_tests/rpl_implicit_commit_binlog.test (or have_binlog_format_row, have_binlog_format_mixed). This is only done because they have different result files. After MDEV-30, one could have one rpl_implicit_commit_binlog.test and three result files rpl_implicit_commit_binlog.row.result rpl_implicit_commit_binlog.statement.result rpl_implicit_commit_binlog.mixed.result Backward compatibility is preserved, because if testname.XXX.result file is not found, mtr will use testname.result file. So, there will be no need to rewrite any tests.
Hope this helps,
Yes. Thanks! Regards, Sergei
participants (2)
-
Kristian Nielsen
-
Sergei Golubchik