In general, these boolean success tests are weak. Where/how do we validate that the table has actually been altered or dropped vs. the command getting silently ignored?
We need to test either support for (or, failing that, prohibition of) sequences like "CREATE TABLE A ...", ["ALTER TABLE A ..." , ...] "DROP TABLE A", "CREATE TABLE A ...".
We should test the error case: "CREATE TABLE A ...", "DROP TABLE A", "ALTER TABLE A ...".

We should test the error case of altering a table so that the max number of columns is exceeded.
We should test the error case of altering a table so that the max total width of columns is exceeded.
We should test the edge case of dropping (to make room) and then adding columns that would otherwise have put us over these limits IF the ALTER commands were executed out of order.
We should test the (error? or supported?) case in which adding columns puts us temporarily over one of these limits but a later dropping of the columns restores an acceptable size.

We should test for error cases if ALTER would invalidate a dependent index or view. A specific example -- you can't change an INT to VARCHAR if it is being SUMmed in a view or getting multiplied in an indexed expression.

We should probably prohibit "ALTER" from directly operating on a materialized view.

Does "DROP TABLE" imply dropping all dependent indexes and views or would that be an error? Regardless, we need a test for this.

"DROP TABLE" is straight-forward enough but there are so many variations of what ALTER can do to a table that it may justify its own junit suite.