Using System.IO.FileSystem.Watcher

[rmnrdi]

I want to monitor a folder for changes and FileSystemWatcher looks like what I need, but I'm having trouble bringing it into my project.

I was able to bring the exact library in via Project Properties CLR GAC, but I'm having trouble bringing it up in my project.

I can only get this far:

dotNET.System_IO. 

Is this even possilbe?

Here's the FileSystemWatcher page from Microsoft.

https://docs.microsoft.com/en-us/dotnet/api/system.io.filesystemwatcher?view=netframework-4.7.2 

Any help would be much appreciated,

Rob

[AlexKaras]

Hi Rob,

I am pretty sure that it is not possible to instantiate a .Net class, provide it with event handlers and start its asynchronious execution using scripting language.

Can you describe your scenario with more details? Maybe some other approach could fit your needs?

[rmnrdi]

We have a program that retrieves lenses from a source folder, processes them, then creates new files and places them in various target directories.

We need a way to monitor a given target directory for changes and then continue with the rest of the test.

Thanks,

Rob

[tristaanogre · Accepted solution]

TestComplete has, built into it, objects for checking folder contents and such.  Look into the aqFileSystem object and associated methods.

Basically, you can set up a while loop using methods from there to check to see if a file is present.  As long as the file is not there, the loop continues.  That's what I would do.

Documentation found at

https://support.smartbear.com/testcomplete/docs/reference/program-objects/aqfilesystem/index.html

[rmnrdi]

The way our program works is it will start grabbing files, one by one to be processed, but they do this asyncronously.  So it's not a specific file I'm looking for, just that no more files are being written to the folder.

I thought about doing a loop and comparing the file count to a new file count of the same folder after t units of time and when those are equal, do a count down and check again.  The situation just isn't unique enough because if the count is equal or not the files could still not be done processing.

The only other thing I can think of is to count how many files of a certain type are in the source folder and then compare that to the number of files in the destination folder. Only when they are equal will the program continue.

So something liket this...

   //Get the number of files to be transferred from the source directory.

  //*Which is a directory I control the contents of

   //Get the number of files, of the file type that will be created from the target directory

  //Add the source directory count to the target directory count

  //*Because there may be files already in the target folder of the type that will be created

  //Loop through and count the target files

 //Only when the number of files in the target directory equals the number transfered + the number already in the target  directory matches, will the program continue.   

Make sense? 

[tristaanogre]

Yup. You should stil be able to use the aqFileSystem object for what you need.

[rmnrdi]

I just found out our system overwrites files with duplicate names, so I have two choices.
1.) Compare each file by name and count only the different files.

2.) Delete the files of that type before I run the test or if I rerun the test.

Which one do you think I'll choose?

[AlexKaras]

Hi Rob,

> We have a program that [...]

So, what is the actual goal of the test? What exactly do you need to verify?

Assuming that you need to verify that some given source file was processed correctly, I would stick to what was suggested by Robert.

If my assumption is correct, than you have a linear synchronous process: get a source file, put it in the source folder, wait until it is processed, get processed file from the target folder and verify that the processing was correct.

If you need to verify something else, for example, that files are not overwritten before they are processed in the case of high load, then this is a different scenario that will require different approach and, maybe, different tool(s).

[rmnrdi]

The regression test I'm creating looks something like this.

1.) Move n files into a directory. Could be 10 or 1,000. Those files are picked up by a program and processed

2.) Wait until those files are processed.  <-This is what I'm working on now.

3.) Move the resulting files from their prospective directories into pre-comparison staging directories.

4.) Compare thoes files against the same output files from a previous version with BeyondCompare

[AlexKaras]

OK... The actual purpose, design and implementation of the test is, obviously, up to you...

Though, assuming that:

-- You are running tests not on the live system in teal time but on some dedicated to tests one and thus you have a control over what source files and when are generated; and

-- 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.

Do you *really* need to do a verification for 1000 files? Do you *really* need even 50 of them for regression? If you have 15 unique data equivalence classes, then you may need 50 files (one for data from within data class and one for upper and lower bourder conditions). But if you don't have this number of data equivalence classes, can you tell me why you may need to generate, process and verify more than 10-20 files?

So I still see your test as:

-- Generate or just put some definite number of source files into the source folder. The source folder must be empty. If you cannot guarantee this, then make a list of source files and use it while waiting for/processing modified ones;

-- Check the contents of the target folder until some processed source file appears there;

-- Verify that the file was processed correctly;

-- As you know the number of source files and their names, repeat the above two steps until all source files are processed and verified.

P.S. Note, that TestComplete is basically functional GUI testing tool that mimics the human and uses scripting language for test code. Like human cannot do more than one action at the moment and because scripting languages are usually single-threaded (Python may be an exception, though in TestComplete it is not recommended to use any multi-threading functionality of script language), test actions are done sequentially, but not in parallel.

If you really need multi-threading (and do not really require actions to be done via GUI), you may consider TestLeft tool (https://smartbear.com/product/testleft/overview/). It is based on TestComplete's engine and technology but tests are created using C# and thus can utilize everything provided by .Net platform.