Question

We use a Jenkins-Slave to execute Selenium Gui test. The slave is started using WebStart and runs on a Windows 7 machine. The test contains the downloading of PDF files that should be checked for existence as well as correctness by looking up texts in it. The problem is, the running Selenium tests do not see the files downloaded by firefox. In fact the process doesn’t seem to see any file in the directory.

The test runs just fine if I execute it on my local machine, straight from the IDE rather than using Jenkins or WebStart at all.

I already considered the following:

• Am I checking the wrong directory? No, I copied the file.getAbsolutePath() to the windows explorer and can see the files. I’m also pretty sure I’m on the right machine.

• Is it a timing issue? E.g. is the file not finished downloading? No, I use WebDriverWait and wait for 30 seconds to find the file, while it takes actually round abound 1 sec to create and download the PDF:

  WebDriverWait wait = new WebDriverWait(driver, 30, 1000);
     wait.until(new Predicate<WebDriver>(){
       public boolean apply(WebDriver driver){
         try{
           log.info("file: " + pdfFile.getAbsolutePath() + ", exists: " + pdfFile.exists() + ", size: " + pdfFile.length());
           // test files content ...
         }
         catch (IOException e){
           return false;
         }
       }
     });
  

Has anybody any idea what could be wrong? Wild guesses are welcome…

UPDATE
I checked the jenkins.jnlp file and it contains “all-permissons” so it should be able to access the file system.

<security>
   <all-permissions/>
</security>

UPDATE 2
To make that clear: I run Selenium tests using Jenkins. Selenium remote controls Firefox and while doing so, PDF files are downloaded. The problem is, the Java process, e.g. my test classes can’t find the files.

Answer 1

Changing my relative path:

new File("downloads/");

to an absolute by calling "getAbsoluteFile" or just use "C:…":

new File("downloads/").getAbsoluteFile();

fixes the problem (but I don’t understand why). This is, because Jenkins sets the user.id and because of bugs in the java.io.File implementation this can cause problems. See this other SO question and this Java bug report.