"The actual goal of the test is to check that files are processed correctly;
I still do not see any reason for asynchronous folder monitoring."
Neither do I. I'm not monitoring the folder asynchronously, the application processes them asynchronously. So looking for an individual file name doesn't help me becuase it could be processed at any time.
"Do you *really* need to do a verification for 1000 files? Do you *really* need even 50 of them for regression?"
Yes I *really" do. We have situations where we regressions test a customer system before we update them to make sure the update will not cause issues. They may run anywhere from 20 to 3,000 jobs a day. The jobs themselves are prescription eyeglasses with all the calculations that go with it and there are a lot of possible combinations of multifocal, materials, frametypes, lens selection.
Do we need to run that many? If you we grab 50 to 75% of labs jobs for a day (depending on how many they run) we can be pretty sure we're getting a good mix.
-- Check the contents of the target folder until some processed source file appears there; Won't work due to the app processing async
-- Verify that the file was processed correctly; Same as above
-- As you know the number of source files and their names, repeat the above two steps until all source files are processed and verified. I'd have to go through all the files in the source folder, read their names into a list, then compare them to the target folder. at some time interval. That's looping through all files in a folder continuously checking each one.
The question I posed wasn't for a particular test, but a part of a test. The part where I need to make sure all the files are done processing. If they're not, and I try to run a comparison , there will be orphaned files and the comparison will fail.
I'm just going to move any files of that type to a folder and slap a date time on it and begin processing. Done. If I run the test again, and there are residual files, the files will be moved into a new folder and it'll start again.
Thanks for the time you took for the reply. Much appreciated!
Something that confused me:
> If they're not, and I try to run a comparison , there will be orphaned files and the comparison will fail.
Does this mean that processing is not one-to-one match but one-to-many one? I.e. that processing of one file results in the output of two or more files?
And still... I have a feeling that I am missing something essential in your explanation...
Even if processing of one source file results in more than one target file, but still assuming that:
-- you have the list of all initial source files that must be processed;
-- you know the rules according to which target processed files are named (i.e. you know that names of target files);
-- files processing is asynchronous but fast enough (i.e. source file is picked up by processing engine and appears in the taget folder within a reasonably short period of time, say, within less than 30 seconds);
then what are you not sure at in the suggested scenario:
-- push source files into the system;
-- wait until the target folder is not empty;
-- get the name of the first file from the target folder and check if it corresponds to the expected target file from the list of initial source files;
-- if more than one target file is produced for one source file then wait until all required files appear in the target folder;
-- verify target file(s) against expected master one(s);
-- remove the name of processed source file from the list of initial source files;
-- if the list of initial source files is not empty (and you are within expected timeout) then repeat above steps (starting from second) until the list of source files is empty. The empty list of initial source files will mean that all files have been processed.
Should this scenario fit your needs?
P.S. If you think that the above scenario cannot be used in your case, could you please, in addition to the description of why it cannot be used, describe your planned scenario in assumption that we found a way to implement asynchronous monitoring of some file system folder?
"Does this mean that processing is not one-to-one match but one-to-many one? I.e. that processing of one file results in the output of two or more files?"
It's one to many, but they're different file types.
"-- get the name of the first file from the target folder and check if it corresponds to the expected target file from the list of initial source files"
The "check if it corresponds" is the problem. Is nots needed. That's a lot of work for just making sure a certain number of files were transferred. I just put the one that are currently in the folder into a new folder with the date and the file type it contains, then I do the transfer. That way, I have a back up of the output files and I only have to check the target directory for a number of files. That number being the same as the original count.
"describe your planned scenario in assumption that we found a way to implement asynchronous monitoring of some file system folder?"
I am NOT monitoring the folder async. The program processes the files async. I think that's where the confusion may be.
Excuse me, but I am still not sure that I got the scenario that you had in your mind when asked about FileSystem.Watcher object in your initial message and I wish you would describe it with more details...
> I want to monitor a folder for changes [...]
The primary idea of the FileSystem.Watcher object is to asynchronously monitor folder changes and then notify you via the provided callback function.
If you just need to get a list of files from some folder, take a look at the aqFileSystem.FindFiles() method provided by TestComplete.
> You seem hung up on this asynchronicity
It is the main idea of FileSystem.Watcher. Monitor the changes and notify you via the callback function. You may get one or more notifications, depending on the filters been set and the actual change in the file's state. You will get the name of the changed file if the rate of the changes is not high and the buffer of the FileSystem.Watcher object did not overflow. Otherwise the notification may be lost and you need to consider some auxiliary code to process the files with lost notifications.
Monitoring assumes immediate action in response. Thus monitoring is asynchronious. I still do not see in your scenario anything that require monitoring and immediate action. So far everything that you have mentioned fits into linear synchronous processing:
-- get folder's state (i.e. get list of files within the folder);
-- process the list;
-- wait a bit if not all expected/required files were found in the folder and repeat the above steps;
-- end or proceed further if all expected files were found in the folder.
Quite simple and linear and that is why I still think that aqFileSystem.FindFiles() should meet your needs.
"I still do not see in your scenario anything that require monitoring and immediate action. So far everything that you have mentioned fits into linear synchronous processing:"
Immediate action does not always mean asynchronous.
You assume that if I use FileSystemWatcher it has to be used asynchronus. Our program processes files asynchronously. Meaning it picks up files one at a time, but if it takes longer to process file 1 then file 2, it writes file 2 first to the directory. It writes them one at a time and I'm only monitoring a single target directory. How is monitoring that asynchronous? FileSystemWatcher can be async till the cows come home, but if the folder being monitored doesn't fit the bill, then things are going to be linear and synchronous. Which FSW can handle just fine as well. Basically, the situation dictates asynchronicity, not FSW. It can handle either situation.
Quite simple and linear and that is why I still think that aqFileSystem.FindFiles() should meet your needs.
Yes. I know. We came to that conclusion on day 1. I've already written it and moved on to other things. You seem to want to debate if I need asynchronous folder monitoring. I don't need it, that's why I never mentioned asynchronous monitoring. I simply mentioned I need to monitor a folder and it looked like FSW would fit the bill.
I appreciate your replies, but I think we've exhausted this.
aqFileSystem.FindFiles() should meet your needs.
Yes. I know. We came to that conclusion on day 1. I've already written it and moved on to other things.
Ah, this is great to know that the problem is solved actually. (As I in no way want to debate )
You assume that if I use FileSystemWatcher it has to be used asynchronus.
This is not my assumption but the way how FSW works. You instantiate its instance, set required monitoring filters, provide callback function(s) and command it to start monitoring. And your code continues. If event been monitored occurs then callback function will be called.
Just a nutshell summary:
-- No, it is not possible to instantiate and use the FileSystem.Watcher object via CLR Bridge and use it from script-based test code. This is not possible because scripting language does not contain means to provide FSW object with required callback functions;
-- As a possible approach, I think that it should be possible to create an ActiveX COM component around FSW, do all setup within this component and make it to trigger some event when FSW executes the callback function. This event can be processed within TestComplete test code. See https://support.smartbear.com/testcomplete/docs/testing-with/advanced/handling-events/about.html and https://support.smartbear.com/testcomplete/docs/testing-with/advanced/handling-events/select-activex... for more details. But I think that this is an overkill for the scenario been discussed.
Yes. That sounds right.
Do you use any Active X or anything using the clr bridge in TC?
I was playing around with it earlier and it seems kind of cool that you have a lot of that functionality at your disposal.
I wasn't sure if it was widly used. You're a community hero and I was wondering if you've noticed a lot of people using these things?
> if you've noticed a lot of people using these things?
I beleive that people use Bridges (CLR and Java) when some required functionality exists in Java/.Net and is absent in TestComplete.
Of top of my head, there were several threads here related to Java-based PDFBox library to work with pdf documents.
I created a script extension to use a .Net-based flavor of Eyes that can be used for visual testing.
Sometimes, functions provided by .Net are handy, for example, to base64 encode/decode data, make valid file name, etc.
However, TestComplete by itself provides a wealth of functionality that in the most of cases fits my needs. But yes, been able to utilize the additional functionality provided by .Net and/or Java is a great option.