Hi, Kristian! On Jan 25, Kristian Nielsen wrote: > <[email protected]> writes: > > > At http://bazaar.launchpad.net/~maria-captains/maria/5.1/ > > > > ------------------------------------------------------------ > > revno: 3129 > > revision-id: [email protected] > > parent: [email protected] > > committer: Sergei Golubchik <[email protected]> > > branch nick: 5.1 > > timestamp: Tue 2012-01-24 15:08:39 +0100 > > message: > > remove few hard-coded checks from mtr > > Why?!?
This was just a followup. Most hard-coded checks were removed long time ago, these I must've missed. In general, the direction I'm moving in is to remove as much of hard-coded special cases from mtr as possible. If one wants to understand what a test is doing, it should be enough to look at test files (testname.*), studying mtr code should not be required. > It's much faster to have the checks in mtr_cases.pm. Otherwise we have > to start and stop the mysqld server(s), which is often the major part > of time spent in a test case. The test suite is slow enough already > ... Yes. I plan to address that too. One idea is to cache check results (like, if have_debug.inc failed once, all debug tests will be skipped at once). MDEV-105 > Also, some of these tests _must_ be in mtr_cases, because just > starting the server and executing the test for "skip" causes a > failure. Eg. I remember that "not_valgrind" works this way, so I think > your change will cause some tests to break in valgrind. I tested before committing (with valgrind too), so I hope it'll work. Those tests that have to be in mtr - they are in mtr. For example "rpl" check - it forces mtr to use a different .cnf template (this can be moved out of mtr too, but I didn't bother). Or your code for "long" tests. I only removed hard-coded checks that can be easily removed. > If we want to improve things so that we have all checks in one place, > I would prefer to move everything into mysql-test-run.pl. In the long > term, not just for skipping tests but for everything. There is so much > cruft in there just do deal with the testsuite being written partly in > perl, partly in SQL (parse warnings...), partly in the mysqltest > language, partly in C (mysqltest), ... I want to have a clear distinction between a driver program, that run tests, and actual tests. Adding new tests shouldn't require any modifications for the driver. Which doesn't mean we cannot "move everything in mysql-test-run.pl" :) If every test is a perl module, and mtr automatically discovers and loads them as needed - then there will be only one language to deal with and everything will be in mtr. But it's a big incompatible change :( Regards, Sergei _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
