Text file data to property list


I have a text file for my data. It has first line as the header for all the values in the file and rest of the lines are values for these. Also, I have around 20 fields in the data file.

Can I convert these header + Values in property list? if so any tips how to convert?

ex file:

Testcase id, username, password, location

Thx in advance.


Here’s one way to do this.

To solve a problem like this, I first like to create a sample data file to work with. Here’s a little script to do that:

// create a data file to work with
set sampleData to {{
Testcase id,username,password,location
put sampleData into file "/tmp/testCaseData"

Here’s a script to read this file and process the data:

// read the data file
put file "/tmp/testCaseData" into data

// turn the data into a list of property lists
set testCases to an empty list
set keys to the first line of data -- use the first line as keys
repeat with n = 2 to the number of lines in data
	get line n of data
	repeat with k = 1 to the number of items in keys
		set aTestCase.(item k of keys) to item k of it
	end repeat
	insert aTestCase into testCases
end repeat

// display the test cases
repeat with each testCase in testCases
	put repeatIndex() & ": " & testCase
end repeat

This script treats the first line of the data file as the key names, which are used in constructing a list of property lists from the remaining lines of the file.

Here is a project I tossed together to spotlight Doug’s previous post, with some extensions for exception handling and automatic email notification upon script failure.

Included is a master script dispatcher, which may take in some data of which we create, or from another program via SenseTalk’s sockets, or a flat file from an test system, or even a hand coded list of scripts to run and post results.

The Main.script leverages the try…catch exception handling structure of SenseTalk. Also used is a powerful concept called script introspection to find if a script has an ‘owner’ when reporting test failures. If there is no owner, a default owner is assigned and notified. Using the RunWithNewResults command will put each test script’s results in its suite’s Results folder. These results can later be sent to script owners via the SenseTalk’s sendmail() attachment property.

There is some nifty exception handling going on as well. RunWithNewResults by definition will toss an exception if a file/script is not available to run. We wrap the call into a try…catch structure just in case someone/thing deletes or removes a script. If the script is present, yet somehow explicitly or indirectly throws an exception and not handled by the script itself, the try…catch by default will not handle the exception. This is how EP’s RunWithNewResults command is supposed to work, allowing ‘the result’ propertly list to be inspected for status immediately upon return (from normal execution or if an exception happens). If the result’s status is not ‘success’, then an error occured and we proceed to throw another exception which will be handled by the very same exception handler which wrapped the RunWithNewResults command in the first place. A very flexible and useful use of try…catch showing off the flexibility of SenseTalk’s exception handling mechanism.

In summary, we parse/generate some data, which in turn is made into some property lists each representing a test case to be run. Each test case is executed with the RunWithNewResult allowing isolated log files to be generated for reporting when an exception occurs. SenseTalks flexible and power try…catch exception handling is used double duty to handle local and called exceptions.

Try downloading this example, open and read the ReadMe.txt file, drag in the helper script to the TestExample suite, and run the Main.script. You will see three test scripts run, without errors. Then you may want to try playing around with throwing exceptions (uncomment the line in Test1.script for example) and see what happens. Maybe you can fill out the values in the notify handler to send practice notifications to you and your test team members when exceptions are thrown.

Some pitfalls and thoughts about this suite and message dispatch approach. It doesn’t handle test script name collisions, so each test script must be named uniquely across all helper suites. This could be handled by large unique script names, or by the opening and closing of suites programmatically using Eggplant’s OpenSuite and CloseSuite commands. The manual dragging of helper suites to the Helper tab panel is not ideal, yet works in the most simple of cases. In more complex situations where many projects are needing testing and needing daily changes, you may want to write a suite dispatcher also and have instead this suite act as the core script running tool and notifier within the suite dispatcher. Also, if your test requirments have dependencies, you may want to add your own rule set controller to handle the execution of test scripts flow control. For instance branching or repeating a test when one or more test scripts fail. All these ideas are left for the reader to explore while shaping a solution to their QA/Testing needs.

Thank a very much for the detailed response!

I have tried SenseTalkDoug’s solution and it worked very well. Will try out Todd’s soln and will update on that .



I am not very clear about your script:
– Make the key/values into property lists for ease of use.
repeat with each line in data
insert PListFrom(keys, it) after testList
end repeat

– this is PListFrom.script
params keys, values

repeat with each item in keys
set plist’s ( cleanUp(it) ) to cleanUp(item repeatIndex() of values)
end repeat

return plist

to cleanUp str – remove leading and trailing white space
return words 1 to -1 of str
end cleanUp
– end
here, Is testList a property list?
If it is, I just write the following script to check what is in the testList

repeat with each item of the keys of testList
put it & “:” & property(it) of testList
put inLoop
end repeat

but this script does not run at all, I don’t know why.

I haven’t looked at this in a while, but it runs fine here on my machine. Following the steps in the README.txt file, I was able to put a breakpoint in during the run of Main.script and find that testList is

((location:"USA", password:"myPassword", "Testcase id":"TC001", username:"myName"),(location:"USA", password:"secret", "Testcase id":"TC002", username:"anotherName"),(location:"Tasmania", password:"ooba-gooba", "Testcase id":"TC003", username:"someoneElse"))

from the dynamically (for this exercise, example) generated text file

$ cat /tmp/testData
Testcase id,username,password,location

which serves as a comma seperated value file (CSV) often used in the world of table/data driven testing. Then there is the big loop which attempts to execute the tests one by one, if any fail notification is sent to the owner.