ETL DATA TESTING

  • I have source side stored procedure.Using which i need to do analysis and write test cases.

    In the stored procedure , they are updating data after wrting the stored procedure.Do any one know how to write testcases for update statments.

    Komal

  • To be honest I do not know of any "Standard" test procedure as you are requesting. But you can do a great deal of "testing", checking for "good practices" by examining the T-SQL statements. I would for example.

    1. Each SP should include a TRY CATCH block - if some mistakes exist the TRY CATCH can be coded to return a appropriate error message.

    2. Each SP should (in my opinion) have a BEGIN / COMMIT / ROLL BACK transaction. To some extent makes each SP check itself and "undo" errors. Try reading this

    http://www.sqlteam.com/article/introduction-to-transactions

    and

    http://www.codeproject.com/KB/database/sqlservertransactions.aspx

    3. Visual examination to insure that each update SP has the appropriate WHERE clause. (MOST IMPORTANT)

    Hope this gets you started.

    If everything seems to be going well, you have obviously overlooked something.

    Ron

    Please help us, help you -before posting a question please read[/url]
    Before posting a performance problem please read[/url]

  • Hi,

    Remember SEAT for testing.

    Table A

    (

    Column1 varchar(4),

    Column2 int

    )

    Setup

    Select a row of data to be updated.

    eg

    Select Column1, Column2 from A where Column1 Is Null

    Evaluate

    Run the test/code

    Insert into A_Changes

    Select Column1, Column2 from A where Column1 Is Null

    go

    Update A Set Column1 = 'TEST' where Column1 Is Null

    Assert

    Select *

    from A

    inner join A_Changes

    on Column2 = Column2

    Tear down (Clean up)

    Drop table A_Changes

    Cheers

    Jamie

    We are the pilgrims, master.
    We shall go always, a little further.
  • As Jamie wrote. Have a specific, curated set of data. Know the opening state, make the change, query for the end state, which you should know.

    To do this right, you should have multiple cases, NULLS, blanks, negatives, etc. Test how your code handles a variety of beginning cases, with rules for how things should end up.

    Note that you won't catch everything at once. Write a few cases you know, but add tests as you discover new issues.

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply