Using CA Application Test › Using the Workstation and Console with CA Application Test › Building Test Cases › Properties › String Patterns

String Patterns

String patterns are special types of property expressions that have a syntax {{ =[:patternname:] }}. For example, to format a first name, the string pattern property could be {{ =[:First Name:] }}. The property would evaluate to a fake first name that looks like a real name.

This behavior is much better than the possibility of dealing with random strings that do not look like a real name. The string pattern functionality supports many patterns in addition to first names: last names, dates, Social Security numbers, credit card numbers, credit card expiration dates, and many more. This fake data comes in the TESTDATA table in the reportdb database.

The recommendation is that if you need a first name in your test case, you use {{ =[:First Name:] }} in a data set. The "{{=[ " part is a signal to use the string pattern and it has a list of things "registered" that it recognizes.

For example, using the following information in a log step:

{{=[:First Name:]}} {{=[:Middle Initial:]}} {{=[:Last Name:]}}

{{=[:Street Address:]}}

{{=[:City:]}}, {{=[:State Code:]}}

{{=[:ZIP Code:]}} {{=[:Country:]}}

SSN: {{=[:SSN:]}}

Card: {{=[:Credit Card:]}} Expires {{=[:CC Expiry:]}}

Phone: {{=[:Telephone:]}}

Email: {{=[:Email:]}}

provides the following response:

Marilyn M Mcguire

3071 Bailey Drive

Oelwein, IA

50662 US

SSN: 483-16-8190

Card: 4716-2361-6304-6128 Expires 3/2014

Phone: 319-283-0064

Email: Marilyn.C.Mcguire@spambob.com

If you run the step again, you get a different set of data. DevTest tracks the number of rows in the test data database and randomly selects a row between 1 and N.

To open the following window, which shows all existing string patterns and the documentation, click the vertical Patterns tab on the far right side of the page.

Implementation Information

The data is stored by default in the reports database in the TESTDATA table.

DevTest Workstation verifies whether there is any data in the TESTDATA table when it starts. If there is no data, then com/itko/lisa/test/data/TestData.csv inside lisa-core.jar is read to load up the database. If reports.db gets deleted for some reason, the test data is recreated. Reading the database is done only at startup and takes approximately 15 seconds.

Creating your own String Pattern

When you add your own data, the only thing to be careful about is to assign the ID correctly. Start with 1 and increase with no gaps until you get to your number of rows.

The string generator code essentially does select * from testdata where ID = 'n' after getting n from a random object. So, ID must be the primary key of the table to ensure efficient lookups.

Example

A good way to get some practice with property expressions is to build a simple test case that has a single step: an Output Log Message. This step only writes to a log and displays the response in the Interactive Test Run (ITR) Response panel. Therefore, you can experiment with using property expressions.

The following example uses the multi-tier-combo test case in the examples directory (multi-tier-combo.tst):

This graphic shows our example in the ITR utility.

These graphics show the Properties tab in the ITR. The tab that is shown is for the step Get User.

This graphic shows the Test Events tabs in the ITR.

Look for the event Property set in the Test Events tab.

Java developers can also take advantage of the BeanShell environment in the JavaScript step to test property expressions.