¿Cómo probar el código que depende de las variables de entorno usando JUnit?

Tengo un fragmento de código Java que utiliza una variable de entorno y el comportamiento del código depende del valor de esta variable. Me gustaría probar este código con diferentes valores de la variable de entorno. ¿Cómo puedo hacer esto en JUnit?

He visto algunas formas de establecer variables de entorno en Java en general, pero estoy más interesado en el aspecto de las pruebas unitarias, especialmente teniendo en cuenta que las pruebas no deberían interferir entre sí.

Las reglas del sistema de la biblioteca proporcionan una regla JUnit para establecer variables de entorno.

import org.junit.contrib.java.lang.system.EnvironmentVariables;

public class EnvironmentVariablesTest {
  @Rule
  public final EnvironmentVariables environmentVariables
    = new EnvironmentVariables();

  @Test
  public void setEnvironmentVariable() {
    environmentVariables.set("name", "value");
    assertEquals("value", System.getenv("name"));
  }
}

Descargo de responsabilidad: soy el autor de las Reglas del sistema.

La solución habitual es crear una clase que gestione el acceso a esta variable ambiental, que luego puede burlarse en su clase de prueba.

public class Environment {
    public String getVariable() {
        return System.getenv(); // or whatever
    }
}

public class ServiceTest {
    private static class MockEnvironment {
        public String getVariable() {
           return "foobar";
        }
    }

    @Test public void testService() {
        service.doSomething(new MockEnvironment());
    }
}

La clase bajo prueba obtiene la variable de entorno utilizando la clase de entorno, no directamente de System.getenv ().

En una situación similar como esta en la que tuve que escribir Test Case que depende de la variable de entorno , intenté lo siguiente:

1. Fui por las Reglas del Sistema según lo sugerido por Stefan Birkner . Su uso fue simple. Pero más temprano que tarde, el comportamiento me pareció errático. En una ejecución, funciona, en la siguiente ejecución falla. Investigué y descubrí que las Reglas del sistema funcionan bien con JUnit 4 o una versión superior. Pero en mis casos, estaba usando algunos frascos que dependían de JUnit 3 . Así que me salté las Reglas del sistema . Puede encontrar más información aquí. La anotación @Rule no funciona mientras usa TestSuite en JUnit .
2. Luego intenté crear la variable de entorno a través de la clase Process Builder proporcionada por Java . Aquí a través de Java Code podemos crear una variable de entorno, pero necesita saber el nombre del proceso o programa que yo no conocía . También crea una variable de entorno para el proceso secundario, no para el proceso principal.

Perdí un día usando los dos enfoques anteriores, pero fue en vano. Entonces Maven vino a mi rescate. Podemos establecer variables de entorno o propiedades del sistema a través de archivo POM de Maven , que creo que es la mejor manera de hacer pruebas unitarias para proyectos basados ​​en Maven . A continuación se muestra la entrada que hice en el archivo POM .

    <build>
      <plugins>
       <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <configuration>
          <systemPropertyVariables>
              <PropertyName1>PropertyValue1</PropertyName1>                                                          
              <PropertyName2>PropertyValue2</PropertyName2>
          </systemPropertyVariables>
          <environmentVariables>
            <EnvironmentVariable1>EnvironmentVariableValue1</EnvironmentVariable1>
            <EnvironmentVariable2>EnvironmentVariableValue2</EnvironmentVariable2>
          </environmentVariables>
        </configuration>
      </plugin>
    </plugins>
  </build>

Después de este cambio, ejecuté Test Cases nuevamente y de repente todo funcionó como se esperaba. Para información del lector, exploré este enfoque en Maven 3.x , así que no tengo idea sobre Maven 2.x .

Creo que la forma más limpia de hacerlo es con Mockito.spy (). Es un poco más liviano que crear una clase separada para burlarse y pasar.

Mueva su recuperación de variables de entorno a otro método:

@VisibleForTesting
String getEnvironmentVariable(String envVar) {
    return System.getenv(envVar);
}

Ahora en su prueba de unidad haga esto:

@Test
public void test() {
    ClassToTest classToTest = new ClassToTest();
    ClassToTest classToTestSpy = Mockito.spy(classToTest);
    Mockito.when(classToTestSpy.getEnvironmentVariable("key")).thenReturn("value");
    // Now test the method that uses getEnvironmentVariable
    assertEquals("changedvalue", classToTestSpy.methodToTest());
}

No creo que esto se haya mencionado todavía, pero también podrías usar Powermockito :

Dado:

package com.foo.service.impl;

public class FooServiceImpl {

    public void doSomeFooStuff() {
        System.getenv("FOO_VAR_1");
        System.getenv("FOO_VAR_2");
        System.getenv("FOO_VAR_3");

        // Do the other Foo stuff
    }
}

Podrías hacer lo siguiente:

package com.foo.service.impl;

import static org.mockito.Mockito.when;
import static org.powermock.api.mockito.PowerMockito.mockStatic;
import static org.powermock.api.mockito.PowerMockito.verifyStatic;

import org.junit.Beforea;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.InjectMocks;
import org.mockito.MockitoAnnotations;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.powermock.modules.junit4.PowerMockRunner;

@RunWith(PowerMockRunner.class)
@PrepareForTest(FooServiceImpl.class)
public class FooServiceImpTest {

    @InjectMocks
    private FooServiceImpl service;

    @Before
    public void setUp() {
        MockitoAnnotations.initMocks(this);

        mockStatic(System.class);  // Powermock can mock static and private methods

        when(System.getenv("FOO_VAR_1")).thenReturn("test-foo-var-1");
        when(System.getenv("FOO_VAR_2")).thenReturn("test-foo-var-2");
        when(System.getenv("FOO_VAR_3")).thenReturn("test-foo-var-3");
    }

    @Test
    public void testSomeFooStuff() {        
        // Test
        service.doSomeFooStuff();

        verifyStatic();
        System.getenv("FOO_VAR_1");
        verifyStatic();
        System.getenv("FOO_VAR_2");
        verifyStatic();
        System.getenv("FOO_VAR_3");
    }
}

Desacoplar el código Java de la variable de entorno proporcionando un lector de variables más abstracto del que se da cuenta con un entorno VariableReader de su código para probar las lecturas.

Luego, en su prueba, puede dar una implementación diferente del lector de variables que proporciona sus valores de prueba.

La inyección de dependencia puede ayudar en esto.

Esta respuesta a la pregunta ¿Cómo configuro las variables de entorno de Java? proporciona una forma de alterar el mapa (no modificable) en System.getenv (). Entonces, aunque REALMENTE no cambia el valor de la variable de entorno del sistema operativo, puede usarse para pruebas unitarias, ya que cambia lo que devolverá System.getenv .

Espero que el problema esté resuelto. Solo pensé en decirle mi solución.

Map<String, String> env = System.getenv();
    new MockUp<System>() {
        @Mock           
        public String getenv(String name) 
        {
            if (name.equalsIgnoreCase( "OUR_OWN_VARIABLE" )) {
                return "true";
            }
            return env.get(name);
        }
    };

Aunque creo que esta respuesta es la mejor para los proyectos de Maven, también se puede lograr a través de reflexionar (probado en Java 8 ):

public class TestClass {
    private static final Map<String, String> DEFAULTS = new HashMap<>(System.getenv());
    private static Map<String, String> envMap;

    @Test
    public void aTest() {
        assertEquals("6", System.getenv("NUMBER_OF_PROCESSORS"));
        System.getenv().put("NUMBER_OF_PROCESSORS", "155");
        assertEquals("155", System.getenv("NUMBER_OF_PROCESSORS"));
    }

    @Test
    public void anotherTest() {
        assertEquals("6", System.getenv("NUMBER_OF_PROCESSORS"));
        System.getenv().put("NUMBER_OF_PROCESSORS", "77");
        assertEquals("77", System.getenv("NUMBER_OF_PROCESSORS"));
    }

    /*
     * Restore default variables for each test
     */
    @BeforeEach
    public void initEnvMap() {
        envMap.clear();
        envMap.putAll(DEFAULTS);
    }

    @BeforeAll
    public static void accessFields() throws Exception {
        envMap = new HashMap<>();
        Class<?> clazz = Class.forName("java.lang.ProcessEnvironment");
        Field theCaseInsensitiveEnvironmentField = clazz.getDeclaredField("theCaseInsensitiveEnvironment");
        Field theUnmodifiableEnvironmentField = clazz.getDeclaredField("theUnmodifiableEnvironment");
        removeStaticFinalAndSetValue(theCaseInsensitiveEnvironmentField, envMap);
        removeStaticFinalAndSetValue(theUnmodifiableEnvironmentField, envMap);
    }

    private static void removeStaticFinalAndSetValue(Field field, Object value) throws Exception {
        field.setAccessible(true);
        Field modifiersField = Field.class.getDeclaredField("modifiers");
        modifiersField.setAccessible(true);
        modifiersField.setInt(field, field.getModifiers() & ~Modifier.FINAL);
        field.set(null, value);
    }
}

Bueno, puedes usar el método setup () para declarar los diferentes valores de tu env. variables en constantes. Luego use estas constantes en los métodos de prueba utilizados para probar los diferentes escenarios.

Si desea recuperar información acerca de la variable de entorno de Java, se puede llamar al método: System.getenv();. Como propiedades, este método devuelve un Mapa que contiene los nombres de las variables como claves y los valores de las variables como los valores del mapa. Aquí hay un ejemplo :

    import java.util.Map;

public class EnvMap {
    public static void main (String[] args) {
        Map<String, String> env = System.getenv();
        for (String envName : env.keySet()) {
            System.out.format("%s=%s%n", envName, env.get(envName));
        }
    }
}

El método getEnv()también puede tomar un argumento. Por ejemplo :

String myvalue = System.getEnv("MY_VARIABLE");

Para probar, haría algo como esto:

public class Environment {
    public static String getVariable(String variable) {
       return  System.getenv(variable);
}

@Test
 public class EnvVariableTest {

     @Test testVariable1(){
         String value = Environment.getVariable("MY_VARIABLE1");
         doSometest(value); 
     }

    @Test testVariable2(){
       String value2 = Environment.getVariable("MY_VARIABLE2");
       doSometest(value); 
     }   
 }

Uso System.getEnv () para obtener el mapa y lo guardo como un campo, para poder burlarme de él:

public class AAA {

    Map<String, String> environmentVars; 

    public String readEnvironmentVar(String varName) {
        if (environmentVars==null) environmentVars = System.getenv();   
        return environmentVars.get(varName);
    }
}



public class AAATest {

         @Test
         public void test() {
              aaa.environmentVars = new HashMap<String,String>();
              aaa.environmentVars.put("NAME", "value");
              assertEquals("value",aaa.readEnvironmentVar("NAME"));
         }
}