Philip Herron wrote:
Hey guys
Just wondering, i have been messing with the code for a while this past 3 days
and i was wondering on a good way to make sure any modifications are tested
properly, like myself first before i send in any patches i make.
I see there are a few binaries to run, but not quite sure the best way to
test! Like what should be done to set up the database then to run some tests
to make sure the code is stable :).
Hi Philip! Well, with the current testing system, here is a quick way
to test your code, but only if it touches stuff that relates to SQL
specifically (meaning, for right now, it doesn't touch replication or
stuff that occurs *before* client connection threads hit the
mysql_parse() routine in sql_parse.cc)
1) Before you begin your modifications, create a test case which will
demonstrate the change in behaviour you look to implement.
To do so, simply create a file called xxx.test. xxx should be some
descriptive name of what you are working on (like a bug number or a
small feature or patch).
2) Place the file in the tests/t/ directory.
3) In the test file, place commands which demonstrate the behaviour you
wish to modify. Commands are simply SQL commands or a variety of
mysqltest commands. The important ones to know for right now are these:
--error XXXX
Place the above *directly before* a SQL command which you expect to
throw an error number XXXX
--disable_warnings/--enable_warnings
Place this as a block around code you don't want to track warnings on.
Typically, this would be around a command such as:
DROP TABLE IF EXISTS t1;
since that will throw a warning if t1 does not exist.
Feel free, of course, to peruse the existing test cases to see examples
of how a test case is laid out. Stick to the simple stuff first, and
don't go down the rabbit-hole of trying to understand all the
test-specific commands. Just stick to the basic SQL commands at first.
4) Make your code modifications.
5) Compile and build Drizzle:
$> ./config/autorun.sh && ./configure --with-debug && make -j2
(you can replace make -j2 with the concurrency level of your choice of
course...usually I set it to the number of cores in the compiling machine)
You will want to configure --with-debug so that you can do code
investigation easily with GDB.
6) Run your test.
$> cd tests
$> ./dtr xxx
Where xxx is the name of the test case you created in step 1)
7) If the test runs successfully, you will see the output of the test
commands along with a message saying something like "results file not
found". This is fine for now. If the test case bombed, you will know,
since it will show the error failure. If it fails, go to step 11.
8) Go ahead and double-check that the results of the SQL commands in
your test case were appropriate and correct. *Be very thorough about
this process!*
9) Once you are sure that the test case produces correct results, you
need to record a results file:
(from the tests/ directory again)
$> ./dtr --record xxx
where xxx is the name of your test case
This will produce a test case results file corresponding to your test
case run and save that file in tests/r/xxx.result.
You can verify a passing test case by running the test case again,
without the --record option. You should see a passing test case printout.
10) Now, any time you make changes, simply compile Drizzle and run your
test case again to verify no regressions.
11) When you encounter failures, it is often valuable to figure out what
is going on via GDB. This is critical if you get an error saying "Lost
connection to Drizzle during query", as this typically means a segfault
occurred on the server and you need to track it down. Follow steps
12-14 to debug Drizzle in GDB.
12) Run your test case with the server in GDB:
$> cd tests
$> ./dtr --gdb xxx
Where xxx is your test case's name
An xterm window will open up with the Drizzle server at the
mysql_parse() function breakpoint, automatically set by the test runner.
I won't go into a full tutorial of how to use GDB (Google exists,
after all) but here is a quick set of things to do:
When in the GDB console:
where<Enter>
will produce the current call stack where you have currently "broken"
at. This is very useful if you run into a segfault and need to know the
backtrace up to where you have received a fault.
step<Enter>
Steps into the next instruction and shows the instruction to you. This
will step "into" each function as you hit it.
list<Enter>
Shows the block of source code you are currently in.
next<Enter>
Jump to the next instruction. This will step "through" a function call,
not into it.
continue<Enter>
Just fires the code through to a segfault or a clean exit.
print xxx<Enter>
Prints the value of the variable xxx (Note, no semicolon before <Enter>)
OK, that's it for now...
Have fun :)
Cheers,
Jay
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
