CODEWITHSUNDEEP
testingautomation
user393148
user393148

Reputation: 957

How to design my test automation

Here is my test scenario.

When a command line executes - lot of values are written to different tables in a db.

There are multiple command line options and many values/tables to be verified in the db. How should I go about designing the check for values in db?

What I done have so far -

Advantage here is that I have to write less code as part of framework. Downside of this is that I have to write more code when developing each tests, not streamlined and I may get column names wrong sometimes.

So I am trying to see if I streamline the check better. Something like declare a class (for a table)with columns as exposed properties. This way i wont get the column names wrong at least.

  1. Is this the simplest approach ( for the long run? I want to write more reusable code). If not, what best way there is?
  2. Is there a easy way to export tables/column values from db to a c# project file (as a class/code) so that I don't have to put everything in code again.

Let me know if any details are not clear or if I would like me to elaborate bit more on the details.

Thanks for looking.

Upvotes: 1

Views: 143

Answers (1)

Michael Venable
Michael Venable

Reputation: 5051

I don't know of a standard approach for this problem, but I'll offer some ideas.

I usually find myself creating classes to represent tables to take advantage of compile-time checks, so I think that's a good way to go. You might want to look into Linq-to-SQL -- I think it can do a lot of this for you. I sometimes use ActiveRecord in Ruby for this purpose, even on C# projects, because development with it is very quick.

Alternatively, you might want to put the tests in text files:

Command: 
command to execute

Expected Data:
SELECT column FROM table;
row name, column name, expected data
row name, column name, expected data
row name, column name, expected data

Expected Data:
SELECT column FROM table;
row name, column name, expected data
row name, column name, expected data

Then write a little code to load and parse your files, run the command, and compare the results. This would factor out only the things that change with each test, so I don't know if it can get much better.

Another idea is to try pulling common code into a base class and keep the varying code in subclasses. This design follows the Template Method pattern.

Example

class MyTest : CommandLineTest {
  public String Command() { return "Command to execute"; }
  public String DataRetrievalCommand() { return "SELECT column FROM table"; }

  public DataResult[] ExpectedData() {
    return [ new DataResult("column", "row", "value"), ...];
  }
}

The superclass will use these methods to get the commands and values, but it will be the one doing all the actual work. Similar idea as the text files, but the test specification is kept in code.

Hope this helps or at least gets a few ideas flowing.

Upvotes: 1

Related Questions