Try to avoid hard-coding paths in your test program if possible, like the ones shown here:
One reason is that paths can change. Once I was given the task to resurrect an old test script. It was a huge script with absolute paths scattered throughout it. Originally, the script came from a different company that was bought out by the company I was working for at the time. I asked former employees of the old company about the directories. They couldn’t remember anything about them. They didn’t even know what happened to the host machines. We had to abandon the old test script.
Another equally important reason to avoid hard-coding absolute paths in tests is that you never want people editing the source code in the test. This is especially true if the tester doesn’t have coding experience. A backslash (“\”) has a special meaning in most languages. It indicates the start of an escape sequence in a string. Maybe an inexperienced tester doesn’t know this so s/he enters a single slash instead of two:
c:\tests\foobar [BAD] c:\\tests\\foobar [GOOD]
The script will execute, but the test will probably fail. Other potential problems may include unwanted trailing or leading white space in the string or those nasty cut-and-paste non-printable characters that seem to come from word processor programs. The test code itself may also get inadvertently altered. Anything could happen, so avoid this altogether.
The solution is to force the user to provide the required paths via the command line or perhaps a configuration file that the test can parse at the start of execution. You may also try adding intelligence in the code to have it ascertain the paths it needs. If all of this is impossible and there is no other way, then at least place the required paths at the very top of the script as variables. Make it clear to the tester how to make the changes by providing examples in the comments. Include a “# Don’t Edit Below This Line” warning as well. Make plenty of backups too.