Here is a small sample test case:

--disable_warnings
DROP TABLE IF EXISTS t1;
--enable_warnings
SET SQL_WARNINGS=1;

CREATE TABLE t1 (a INT);
INSERT INTO t1 VALUES (1);
INSERT INTO t1 VALUES ("hej");

The first few lines try to clean up from possible earlier runs of the test case by dropping the t1 table. The test case uses disable_warnings to prevent warnings from being written to the output because it is not of any interest at this point during the test to know whether the table t1 was there. After dropping the table, the test case uses enable_warnings so that subsequent warnings will be written to the output. The test case also enables verbose warnings in MySQL using the SET SQL_WARNINGS=1; statement.

Next, the test case creates the table t1 and tries some operations. Creating the table and inserting the first row are operations that should not generate any warnings. The second insert should generate a warning because it inserts a nonnumeric string into a numeric column. The output that results from running the test looks like this:

DROP TABLE IF EXISTS t1;
SET SQL_WARNINGS=1;
CREATE TABLE t1 (a INT);
INSERT INTO t1 VALUES (1);
INSERT INTO t1 VALUES ("hej");
Warnings:
Warning 1265    Data truncated for column 'a' at row 1

Note that the result includes not only the output from SQL statements, but the statements themselves. Statement logging can be disabled with the disable_query_log test language command. There are several options for controlling the amount of output from running the tests.

If there was a test failure, it will be reported to the screen. You can see the actual output from the last unsuccessful run of the test case in the reject file r/test_name.reject.