This is a discussion on Dealing with write protected documents in TestAutomation - Solaris Rss ; Hello everyone, for some time now we've been fighting with a problem in TestAutomation that we never managed to solve for good: Dealing with write protected documents. This problem primarily hits Oracle QA but can also happen to testers outside ...
for some time now we've been fighting with a problem in TestAutomation that we never managed to solve for good: Dealing with write protected documents. This problem primarily hits Oracle QA but can also happen to testers outside of Oracle.
To avoid tampering with a "tagged" Mercurial (HG) repository we make it read-only. This makes it impossible for anyone to manipulate a revision and encourages sticking to the CWS handling guidelines. However, this also comes with price. In this case it is that we open all test documents with write protection. As a consequence we currently have a function called sMakeReadOnlyDocumentEditable() which did not always work as it should, usually caused by bad timings.
To finally get rid of this we discussed several options but weren't too happy with any of them. The one with the lowest impact on performance was to enforce creating a local copy of a file within the users work directory.
In CWS automationdev300m87 i have started to implement the functionality and the first impressions are positive. A new function was introduced
hFileOpenLocally( Filename )and two functions have been removed
sMakeReadOnlyDocumentEditable()The new function hFileOpenLocally( Filename ) works as as a drop-in replacement for hFileOpen( Filename ):
It is called the same way as hFileOpen( Filename ) but
- Checks the presence of the source file
- Copies it to the local user directory keeping the filename but junking the path
- Stores the current filename into the global variable gLastWorkFile (for possible later usage)
- Opens the file using hFileOpen( Filename )
To extract the filename from the original path and to determine the new location a few more helper functions were introduced and/or copied from optional include files into the required ones to ensure they are available from everywhere:
hGetWorkPath() as string which returns the work path from API (or uses fallback)To avoid unnecessary copy operation it was decided to implement the function in such a way that a file that has already been copied will not be copied again. This is in so far safe as our policies say to remove the user installation before each test and we've checked that not two different files with identical names are copied within one test-block (.bas-file).
hGetWorkFile( Filename ) as string which appends a filename to the work path with just one call
hSplitString( String, Separator, index ) as string allowing to get the filename from a path
The big drawback of this function is that it will not work on files which already are stored locally and - if you want to re-use a filepath you need to retrieve it from the global variable gLastWorkFile.
It is most likely going to take some time to get the CWS integrated - probably not before DEV300m90 - but you are welcome to provide comments and suggestions while the CWS is progressing.
Read More about [Dealing with write protected documents in TestAutomation...