Why is testing a transformation important even when the SQL executes without error against production data?
Select an answer to reveal the explanation.
Short Explanation
Running clean doesn't mean correct. You need tests with known inputs and expected outputs to catch join fan-out, wrong filters, and bad casts that run without error.
Full Explanation
The correct answer is the option stating that successful execution proves the statement is valid, not that the logic is right, because join fan-out, wrong filters, and bad casts all run cleanly. The engine validates syntax, types, and references. It cannot know your intent, so logic errors execute happily: a join on a non-unique key multiplies rows, an over-restrictive filter drops a segment, and a cast turns unparseable values into nulls. Testing with known inputs and expected outputs is what distinguishes valid from correct.
The option claiming SQL errors are only reported after the transaction commits is incorrect because syntax and reference errors are raised before execution, not after commit.
The option claiming untested SQL cannot be registered in the catalog as a pipeline step is incorrect because the catalog registers tables and their metadata. It does not gate pipeline steps on test status.
The option claiming testing is required to keep the engine's query plan cache warm is incorrect because plan caching is a performance mechanism entirely unrelated to correctness.
For the exam, remember that join fan-out is the most common of these and the least likely to raise any error at all.