Testing Tool: FileHamster

FileHamster is awesome. If it hasn't already arrived at your city - pillaging it with paws of gargantuan awesome-ness (paw-someness?) - then consider yourself both deprived AND unfortunate. Download it from here. I've been using this tool for about 1.5 years now and always come back to it.



In a nutshell, Filehamster is a glorified directory monitor that acts as a kind of localized source control. The developers originally intended it to allow creative types to work without the fear of being unable to undo their Picasso-esque changes. Anyone who has made modifications to a document, then closed the application only to realize that was in fact NOT the modification you wanted, can attest to this problem. Here's how it works from a 3048m view:

- Create a new directory/file watch
- Operate your application, saving changes will-nilly
- Observe that FileHamster captures each successive save

"No bug whoop!", you exclaim. "The .Net framework has a FileSystemWatcher class that lets me do the same thing!" That is true. Who hasn't written this kind of program before using that very class. However the ease of use, visibility of changes in real-time, and the diff plugin are benefits that keep this high on my desert island list of exploratory testing tools.

An example would be good here:
If I have a fat client application to test, one of the first things I do is pop open FileMon to observe its file system traffic for log files, artifacts, etc. Once I determine the directories where these files are written to, I create a new recursive directory watch in FileHamster. Even better, I can filter the types of files that it captures, thus reducing the potential for data overload. I then proceed to explore the app some more. Meanwhile, FileHamster is dutifully running in the background capturing all the file system changes into discrete time-stamped files and alerting me when it does so.

After a session, I can come back and observe the captured files. FileHamster honors any file associations; it will open the file in its associated application, e.g. TXT in notepad, MDB in Access, etc. This ability to observe a session's change history is valuable in-and-of itself. However, the diff plugin allows me to specify a comparison application as well. I can select two of the captured files and launch the comparison application via a context menu. Now I can see what changed in the document while I was testing away.

Experience Report...nnnNNNOW!:
I've used this approach while testing some financial applications that persisted actuarial debug values in a kind of CSV file. I would run a plain vanilla case, then run an alternate solve that should have given me the exact same answer. Both tests produced the CSV file. When I encountered a problem, I simply compared the known good (did I mention you can assign comments to the captured versions in this thing?) to the variant version and observed precisely where the diff was introduced. I don't need to be an ASA to tell you that a different max allowable loan value in year X could have significant ramifications on a Universal Life policy and its later-year cash values.

The only problem I've encountered is that I'm only able to specify one diff application. I've worked around this by creating a stub utility that maps all my diff applications by file extension. That way, my .xls files are compared in my custom Excel file utility, .PDF files are compared in another, etc. I may post my comparison stub script later, but it is simple enough to script in a language of your choice.

Download FileHamster and check it out. It runs on Windows and requires .NET 2.0. I want to say that I've also been able to run it off a thumb drive, so portability may be a benefit. Let me know what you think.