Better way of creating test using loop

[ching ping]

Hi Telerik team,

I have a web application with a textbox that allow users to key in serial ID. After the user key in the serial ID in the textbox, they'll press enter and the serial ID will be displayed in a listbox (refer to serialid.jpg on how the UI looks like).

I want to create a test that input serial ID in the textbox for 100 times(every ID must be unique) and the listbox will be displaying the 100 serial ID. Instead of using data driven feature that bind the serial IDs to the textbox, is there any better way to create the test, like using loop?

[Nikolai]

Hi ching ping,

I think using The Data Driven approach will work best for a scenario like yours. You can use loop step but it will be more complicated :

1. Create a coded step like this:

private int i = 0;

[CodedStep(@"Get Data")]
public void WebAiiTest1_CodedStep()
{
    //Set the id here


    //Increment counter
    this.i++;
}

The counter can be used to increment your ID so it will be unique each time.

2. Add the above coded step to a "Loop" step that will be executed 100 times.

Hope this helps.

All the best,
Nikolai
the Telerik team

[Cody]

Hello ching ping,

Here's another approach that avoids resorting to code:

1. Create a main test that performs all the actions necessary to get to the point of entering the unique serial ID's
2. Create a subtest that enters one unique ID and nothing more. This subtest assumes you're already at the page to enter the unique ID's.
3. Databind the subtest to a data source (e.g. an Excel spreadsheet) and put the unique ID's in the data source.
4. Call the subtest via Test-as-step from the main test
5. After calling the subtest add steps to the main test that verifies the unique ID's are contained in the list. Or call another subtest that is databound to the same datasource and verifies the list contains each unique ID, one at a time.

Will this approach work for you? Do you also need to re-generate new unique ID's every time the test runs? If so the above can still be used but we'll have to add a way of generating and storing the unique ID's so they can be entered and verified they are contained in the list.

Regards,
Cody

the Telerik team

[STEVEN]

Can I conclude that the recommended way is the Data Driven approach, like what Cody had recommended?

[Cody]

Hello STEVEN,

The real bottom line is that what is recommended is whatever works best for your testing environment that meets your test case requirements. Generally it is better to avoid having to write code when implementing a test, but that certainly is not a hard and fast rule. The more code yuo can avoid having to implement then generally the easier it is to maintain test in the event of changes to the applicatiion or the test case requirements. Having to modify code to fix a broken test usually is relatively expensive in terms of the time spent maintaining a test.

Based on what I understand of the test case, I would choose based on whether or not re-using the same set of unique ID's everytime the test runs meets the test case requirements. If a new set of ID's needs to be generated for each test run, then code is really the only way to go (a data driven test cannot generate new data input on the fly). If re-using the same set of ID's is acceptable then I would go with the data driven setup I previously described.

What are your thoughts?

Regards,
Cody
the Telerik team

[STEVEN]

I reason along the same thoughts you have.
Data driven is the way to go.