Anyone know of a good way to delete rows from a file? In my current AUT I'm running a script that grabs some data from a column in a csv file. Once I successfully complete the transaction, I can no longer use that row again. I had previously written some convoluted code to execute at the end of a test that would read all the items from a file I created during the script that contained all the values used in that test cycle, find them in the original file, and set the file pointer to where it was found and delete 19 bytes which was the known length of each row. However in the current incarnation the row length is variable so I can no longer operate in that fashion. If it's any help here's my previous code (in this instance I am actually cycling through 3 seperate files, one for used(good), one for items with unknown errors, and one with discovered bad conditions).
<font class="small">Code:</font><hr /><pre> for FNIterate := 1 to 3 do
sFileName1 := aFileNames[FNIterate];
if nSize > 0 then
nMaxRows := FileGetNumRows(hCSV);
nCount := nMaxRows;
Print("# of iterations from "+sFileName1+" is "+string(nMaxRows));
for nIterate := 1 to nMaxRows do
sSearch := FileGetCol(hCSV,1);
bFound := FFindString(hVins1,sSearch);
if bFound = true then
Print("Vin found at position "+string(nPoz));
Print("VIN not found");
nCount := nCount -1;
print(string(nCount)+" iterations to go");
print("File "+ sFileName1+" is empty");
We have a very similar data problem with our testing. We can only register users on the system that haven't been registered before and once they are registered we can't use the data to re-register someone. And we can't login util a user has been registered and so forth.
When dealing with data dependencies like that you might want to consider moving to using a database to manage your test data. That way when you've used a record in the DB that can't be used anymore, you can easily set a flag not to use that data, or to delete it altogether. This way our registration tests can begin with a query to go get the next unregistered user in the test data DB. Once the user is registered we can flag the user as 'registered' and then other scenarios that need a registered user can query for and use that data too.
Best of all, building a solution like that doesn't take a lot of time and actually saves a lot more time than you are probably spending currently trying to manage data files.