Testing filesystem interactions of a simple copy app

Testing Thoughts
#1

I have a chance to do a bit of fresh testing of a feature which essentially just copies a file, portably (Meaning the app is compiled for Macs/linuxes and Windows10) , and merely copies a file from one folder to another, not between O/S. Basically on the same computer. What kinds of unusual files and what kinds of unusual behaviours can I test against?
To constrain the initial discussion I’m adding a few arbitrary exclusions:

  1. File copy over network is another topic, or between 2 different O/S over network which in reality should be covered in the simple stand-alone domain problem anyway if we cover it properly.
  2. The app has no commandline, it’s interface is GUI only (there is a internal API at any rate, but I’m not testing the API, I’m testing the functionality)
  3. In future, the program will automatically unzip zip files for you as a way of copy folders around more easily. But for now lets assume it does not.

So far I have my usual suspects:

  1. zero length
  2. destination file has archive bit cleared after the copy (Windows)
  3. destination file is read-write
  4. source file has write locks open should prevent the copy process starting.
  5. program shall lock the file against writes
  6. destination file would exceed storage quota checks regularly
  7. destination file disappears while saving to it?
  8. source file contains file-streams (Windows)
  9. source file is an executable (OS dependant outcomes??)
  10. source filename is case sensitive/filesystem case sensitive
  11. source file gets a (1) suffix if destination exists
  12. source filename with a “(1)” suffix gets renamed to “(1)(1)” if destination with (1) exists etc…
  13. destination file would exceed path lengthcheck
  14. source filename with no “filetype” (OS dependant treatment)
  15. source filename with multiple filetype “extensions” or suffixes handled
  16. source file contains virus signature (that may trigger a personal filesystem firewall??)
  17. source file conflicts when a destination folder of same name exists must append a (1) suffix. (OS dependant??)
  18. Unicode and UTF-8 (with no BOM mark) files are implied, any gotchas in this area?
  19. simultaneously transfer multiple files using the GUI
  20. cancel an individual file transfer
  21. stop all file transfers
  22. resume unsupported : Resuming a transfer is out of scope here, but any ideas are welcome.

Pretty sure I can group these or map these much better; but before I try to, which ones have I missed?

#2

There might be some overlap with your list. Here are some additional cases:

  • The permission of the source file changes during the copy. (Owner, group, general)
  • The target subdirectory or folder is read only for the user of the app.
  • The permission of the target subdirectory changes.
  • For specific Windows 10 files system administrator rights are required for copying.
  • The copy action is started, while a similar action (same file and target subdirectory) has already been by another or same app.
  • There is not enough disk space for all the files to be copied. What options are offered by the app to make an informed decision?
  • The target subdirectory is deleted just after the start of the copy action.
  • The target subdirectory is renamed just after the start of the copy action.
  • The target subdirectory is moved just after the start of the copy action.
  • Speed. The optimal size of file chunks is determined based on the used programming language.
  • In the target folder there is a file with the same name as the file to be copied. Does the app give the option to overwrite this file? If yes, what happpens if the file to be overwritten has special properties like read only or write lock.
  • Possible missing requirement: Option to copy the files after each other instead of all files at the same time.
#3

I did manage to acquire a few more
35. Destination is a device con/printer name
36. Copy between different filesystems example from FAT32 to NTFS (or a mounted flash drive)
37. Copy to a folder by symlink/hardlink name
38. Preserve file attributes
39. Copy batch of files where some files will fail but no prevent legitimate files copying successfully
40. Transfer several files with the same name (if the app allows to set an individual name when you do a bulk copy)

(sorry, I fixed my issue and numbered these, my brain was not engaged fully.)
26, I had honestly not thought about how to test that one, it’s implicit, but still needs coverage. :smiley:

7,29,30,31 are all together really variations of 4,5,7. So those need grouping.

33 is kind of sitting as a UX test, because 11 and 12 describe the desired behaviour for duplicates. This was because we want to reduce UI to absolute minimum, but 33 and 34 are definite keepers for UI test cases.

32 , Speed is probably the biggest one I was never going to think of and is the biggest issue to look at of them all, probably because its a non-functional test. Amazed at how a non-functional test can be super critical here. Nice work @han_toan_lim

1 Like
#4

Is there any feedback to the user with this feature? Tests could be put in around that e.g. alerting when done, or an issue has occurred?

Are there any logs that get produced somewhere to capture issue information?

Edit - also, what about if the file is initially corrupted? Should that move successfully?

1 Like
#5

ad 22) My gut feeling is that also network and hard disk should be taken into account for the optimal file chunk size:

  • What is the best file chunk size for a data packet?
  • What is the best file chunk size for the file block size of different operating systems?
  • What is the best file chunk size for the file block size on a hard disk?
  • What is the best file chunk size for the file block size on a USB stick?

According to me this needs more exploration.

1 Like
#6

@moorpheus I like your suggestion here, because our fictitious app MUST notify the user prominently when it encounters a corrupted file. Notifications like #7 or #39 imply the user gets alerted. Corrupted files is a layer-2 problem, which could be simulated by physical media removal (flashdrives). Unfortunately I have “decided” that logging is out of scope this exercise. :smiley:

  1. User gets notified when all files successfully transferred
  2. File corruption or unexpected media removal (flashdrive unplugged) Notifies the user immediately error occurs.

This is a brilliant one, because have seen so many times where app code goes into retry loops and crashes out if real hardware failures occur. Nice spot!

1 Like
#7

All in all these are a ‘layer-2’ concern, and I don’t want to loose this train of thought, because every idea is valuable. This ties in with #32 , but is entirely separate!

In my application, the system copies files from A to B using an arbitrary block size, sometimes this might even be out of your control in reality if you are using a UDP or TCP data channel with Nagel algorithm disabled for example. So I’m going to turn this into a few more.

  1. If file transferred over network, check that network proxy is honoured.
  2. If file transferred over network, check the internal network transport configuration (access to source code and advanced tools and domain knowledge required.)
  3. Devise tests that perform boundary analysis by using file of sizes that correspond to the internal transfer buffer or chunk sizes looking for off-by-one errors.
  4. Transfer a file to or from a variety of different flashdrive sizes, check that no performance variations are detected. Pay attention to the device block-size parameters, trying to find bottlenecks.
1 Like