Skip to content

🇮🇳 Independence Day Special Offer – Learn More, Pay Less!

ETL Testing40 min

SQL Validation Lab

The six checks that make up almost every ETL test plan — metadata, record count, duplicates, nulls, column mapping and minus — each one a real query with its failures highlighted in the result grid.

  • 01

    Every check runs against the same seeded defects, so a pass or fail here is a genuine outcome, not a canned message.

  • 02

    Failing rows are marked in the result grid. Red is a defect, amber is a warning worth explaining.

  • 03

    Run the ETL Pipeline lab first and the transformation and target-side MINUS checks turn green, while the source-side checks stay red — a good load rejects bad data, it does not clean the source.

Test plan

7 checks, each one a real query against the seeded defects

  1. PRAGMA table_info(src_sales);
    • src_sales.cidmissingtgt_sales.cidmissingColumn not found on one side
    • src_sales.customer_namemissingtgt_sales.customer_namemissingColumn not found on one side
    • src_sales.productmissingtgt_sales.productmissingColumn not found on one side
    • src_sales.amountmissingtgt_sales.amountmissingColumn not found on one side
    • src_sales.sale_datemissingtgt_sales.sale_datemissingColumn not found on one side

    Every source column arrives as TEXT because the extract is a flat file, so each mapping into the typed target needs an explicit cast. Skip it and the engine stores what it was given: land this extract in stg_sales as-is and 20 amounts convert to REAL, while "63,000" stays text in a REAL column because it is not a number. Nothing errors. The data is simply wrong.

Run something and the rows land here.

Booting SQLite