MariaDB testsuite updated and pushed. Removed a test for working with binlog as of course v3 is just a shim and doesn't allow writes at all. Updated the basic test with a few changes/enhancements.
In a mysql binary install cd mysql-test ./mysql-test-run.pl ... where ... is for instance --suite="oqgraph-" to just run our suite without anything else review results in var/log/mysqltest.log --record="testname.test" if there are no aborts, results will be recorded in var/log/testname.log this you can then verify and copy back to suite/oqgraph/r/testname.result There's a README in the mysql-test directory but the above is nice and specific for us. Tests are in suite/oqgraph/t/testname.test and then the corresponding result file has to match up with the output it actually produces for the test to pass. This is part of the tests run by the build system to validate a build so the more comprehensive the tests, the better! ----- Original Message ----- From: "Arjen Lentz" <ar...@openquery.com> To: b...@andrewmcdonnell.net Cc: oqgraph-dev@lists.launchpad.net Sent: Friday, 1 March, 2013 8:47:25 AM Subject: Re: [Oqgraph-dev] Regression test for attribute segfaults Hi Andrew > I made a regression test for this series of bugs > (How to run it is in the top of the file) > regressiontest.sql.in > So this should run without crashing mysqld, before these were fix > several of the cases crashed mysqld. Should put this into the MySQL testsuite for OQGRAPH. Indeed it's good to have a testcase for each fixed bug, to prevent regressions. MySQL AB used to do that, Monty Program does it, unfortunately Oracle has stopped doing it so Monty Program has to create them if they merge fixes (but often they fix them before Oracle does anyway). Look at mysql-test/suite/oqgraph which has an over. I'll see if I can update the existing minimal stuff for v3 quickly, then I'll push that. > When I get back to this I will move on to preventing the table being > created if the necessary types are missing (aka CREATE VIEW) Note that I already pushed a few fixups (check for empty strings) and cleanups in to your tree yesterday. Did you pull that along the way? You need to start doing that, to prevent duplicate work and such. In the land of distributed version control, attaching a patch file to a bug is not really practical. You can link a bug to a branch(tree) so it's clear where the fix resides and it can be referenced in that way. Should the be a problem, we can always undo an individual revision, not merge a branch into mainline, and so on. Enough options. Cheers, Arjen. -- Arjen Lentz, Exec.Director @ Open Query (http://openquery.com) Australian peace of mind for your MySQL/MariaDB infrastructure. Follow us at http://openquery.com/blog/ & http://twitter.com/openquery -- Mailing list: https://launchpad.net/~oqgraph-dev Post to : oqgraph-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~oqgraph-dev More help : https://help.launchpad.net/ListHelp -- Arjen Lentz, Exec.Director @ Open Query (http://openquery.com) Australian peace of mind for your MySQL/MariaDB infrastructure. Follow us at http://openquery.com/blog/ & http://twitter.com/openquery -- Mailing list: https://launchpad.net/~oqgraph-dev Post to : oqgraph-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~oqgraph-dev More help : https://help.launchpad.net/ListHelp
