Question

My process simply add some content to the system variable PATH. Actually I’m doing this with a Process that use the setx.exe:

public void changePath(String newPath ) {
  String path = System.getenv("PATH") + ";";
  String[] cmd = new String[]{"C:\\Windows\\System32\\setx.exe", "PATH", 
      path+newPath, "-m"};
  ProcessBuilder builder = new ProcessBuilder(cmd);
  ...
}

So I tried to write a test case to it.

Class UpdatePathTest {

  @Test
  public void testUpdatePath() {
    //call the method that update the path
    changePath("C:\\somebin");
    assertTrue(System.getenv("PATH").contains("C:\\somebin")); //fails
    // ProcessBuilder with command String[]{"cmd", "/C", "echo", "%PATH%"}; will fail too.
    //and the above in a new Thread will fail too.
  }

}

So, is there any way to get the new PATH value? Writing the new path is the only option, because I’m developing a jar that will install a desktop application.

Answer 1

I’m not sure changing the path is a good idea in a unit test. What if the test fails? You will have to make sure you do all the relevant tidy up.

Consider inverting your dependencies and use dependency injection.

This article explains it quite well I think.

So instead of having a method that does:

public void method() {
    String path = System.getenv("PATH") + ";";
    //do stuff on path
}

consider doing:

public void method(String path) {
    //do stuff on path
}

which allows you to stub the path. If you cannot change the signature of the method then consider using the factory pattern and using a test factory to get the path.

EDIT: after update to question

What you have to think about here is what you are testing. When you call C:\Windows\System32\setx.exe you have read the API docs and are calling it with the correct parameters. This is much like calling another method on a java API. For example if you are manipulating a list you “know” it is zero based. You do not need to test this you just read the API and the community backs you up on this. For testing changePath I think you probably what to test what is going into ProcessBuilder. Again you have read the API docs and you have to assume that you are passing in the correct variables. (See //1 at bottom) And again you have to assume that ProcessBuilder works properly and that the Oracle (or most likely Sun) guys have implemented it to the API documents.

So what you want to do is check that you are passing variables to ProcessBuilder that match the specification as you understand it. For this you can mock ProcessBuilder and then verify that you are passing the correct parameters and calling the correct method on this class.

In general it is a hard one to test because you don’t want to test the windows functions but want to test java’s interaction with them.

//1 The main problem I have had with calling this external commands is understanding the API documents correctly or setting up the command. Usually you have to get the command line out and check that you are using methods correctly (esp cmd functions). This can mean that you work out how to use the cmd function, code it into ProcessBuilder and then write a test (or vice versa on the ProcessBuilder/test) Not the ideal way but sometimes documents are hard to understand.