Forum Discussion

awhawh's avatar
awhawh
Contributor
7 years ago
Solved

Scripted database checkpoints - best practices

Hi

I'm currently in the process of validating test results and I believe creating database checkpoints is a quick and efficient way of validating results without having to waste time running through potentially lots of screens validating the contents of fields and grids etc (a lot of them). I'm also confident with creating SQL queries.

So I'm obviously interested in using database checkpoints; however, I can see that the database checkpoint wizard forces the user to use a fixed connection string, whereas I need the flexible to use different databases

Ideally I would create a new script that allows the user to use some project variables to construct the connection string, to pass in a parameter to define the sql query and a parameter to define the pre-validated results file that will be used to validate the results of the query

Could something provide some guidance as to the best approach to creating bespoke scripted database checkpoints and how I should store the pre-validated results and how to call them when validating the results of the SQL query

Thanks

Adam

  • What I've done in the past is use the ADO object to create my own custom SQL queries.  These I would then execute against the SQL database to retrieve the required data.  Verification of that data would depend upon what it is I need to be looking for.  If I'm just querying for a single value, then it's a simple comparison of the result of the query to the baseline value, either parameterized from another function or retrieved from a data record in a data-driven framework structure.  

     

    If I need to compare a whole table, what I've done in the past is created my baseline as a CSV file that I store with the rest of my automation source code.  The SQL query then returns an ADO RecordSet which I loop through along with the CSV file and do a comparison of the data in the record set with the data in the CSV file.

     

    For doing custom queries, variable connection strings, etc., this is what I would do.

     

    To assist you, I do have a script extension I created a bit ago that encapsulates a lot of the SQL query code so you don't have to write it yourself.  If you're interested, check the link in my signature.  

2 Replies

  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor

    What I've done in the past is use the ADO object to create my own custom SQL queries.  These I would then execute against the SQL database to retrieve the required data.  Verification of that data would depend upon what it is I need to be looking for.  If I'm just querying for a single value, then it's a simple comparison of the result of the query to the baseline value, either parameterized from another function or retrieved from a data record in a data-driven framework structure.  

     

    If I need to compare a whole table, what I've done in the past is created my baseline as a CSV file that I store with the rest of my automation source code.  The SQL query then returns an ADO RecordSet which I loop through along with the CSV file and do a comparison of the data in the record set with the data in the CSV file.

     

    For doing custom queries, variable connection strings, etc., this is what I would do.

     

    To assist you, I do have a script extension I created a bit ago that encapsulates a lot of the SQL query code so you don't have to write it yourself.  If you're interested, check the link in my signature.  

    • awhawh's avatar
      awhawh
      Contributor

      Excellant. Thanks for your help