En JUnit 3, podría obtener el nombre de la prueba actualmente en ejecución de esta manera:

public class MyTest extends TestCase
{
    public void testSomething()
    {
        System.out.println("Current test is " + getName());
        ...
    }
}

que imprimiría "La prueba actual es testSomething".

¿Hay alguna forma inmediata o simple de hacer esto en JUnit 4?

Antecedentes: Obviamente, no solo quiero imprimir el nombre de la prueba. Quiero cargar datos específicos de la prueba que se almacenan en un recurso con el mismo nombre que la prueba. Ya sabes, la convención sobre la configuración y todo eso.

JUnit 4.7 agregó esta característica que parece usar TestName-Rule . Parece que esto te dará el nombre del método:

import org.junit.Rule;

public class NameRuleTest {
    @Rule public TestName name = new TestName();

    @Test public void testA() {
        assertEquals("testA", name.getMethodName());
    }

    @Test public void testB() {
        assertEquals("testB", name.getMethodName());
    }
}

JUnit 4.9.xy superior

Desde JUnit 4.9, la TestWatchmanclase ha quedado en desuso a favor de la TestWatcherclase, que tiene invocación:

@Rule
public TestRule watcher = new TestWatcher() {
   protected void starting(Description description) {
      System.out.println("Starting test: " + description.getMethodName());
   }
};

Nota: La clase que contiene debe declararse public.

JUnit 4.7.x - 4.8.x

El siguiente enfoque imprimirá los nombres de los métodos para todas las pruebas en una clase:

@Rule
public MethodRule watchman = new TestWatchman() {
   public void starting(FrameworkMethod method) {
      System.out.println("Starting test: " + method.getName());
   }
};

JUnit 5 y superior

En JUnit 5 puede inyectar, lo TestInfoque simplifica los metadatos de prueba que proporcionan los métodos de prueba. Por ejemplo:

@Test
@DisplayName("This is my test")
@Tag("It is my tag")
void test1(TestInfo testInfo) {
    assertEquals("This is my test", testInfo.getDisplayName());
    assertTrue(testInfo.getTags().contains("It is my tag"));
}

Ver más: JUnit 5 Guía del usuario , TestInfo javadoc .

Intenta esto en su lugar:

public class MyTest {
        @Rule
        public TestName testName = new TestName();

        @Rule
        public TestWatcher testWatcher = new TestWatcher() {
            @Override
            protected void starting(final Description description) {
                String methodName = description.getMethodName();
                String className = description.getClassName();
                className = className.substring(className.lastIndexOf('.') + 1);
                System.err.println("Starting JUnit-test: " + className + " " + methodName);
            }
        };

        @Test
        public void testA() {
                assertEquals("testA", testName.getMethodName());
        }

        @Test
        public void testB() {
                assertEquals("testB", testName.getMethodName());
        }
}

El resultado se ve así:

Starting JUnit-test: MyTest testA
Starting JUnit-test: MyTest testB

NOTA: ¡Esto NO funciona si su prueba es una subclase de TestCase ! La prueba se ejecuta pero el código @Rule simplemente nunca se ejecuta.

Considerar el uso de SLF4J (Fachada de registro simple para Java) proporciona algunas mejoras ordenadas usando mensajes parametrizados. La combinación de SLF4J con implementaciones de reglas JUnit 4 puede proporcionar técnicas de registro de clase de prueba más eficientes.

import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.MethodRule;
import org.junit.rules.TestWatchman;
import org.junit.runners.model.FrameworkMethod;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class LoggingTest {

  @Rule public MethodRule watchman = new TestWatchman() {
    public void starting(FrameworkMethod method) {
      logger.info("{} being run...", method.getName());
    }
  };

  final Logger logger =
    LoggerFactory.getLogger(LoggingTest.class);

  @Test
  public void testA() {

  }

  @Test
  public void testB() {

  }
}

Una forma complicada es crear su propio Runner subclasificando org.junit.runners.BlockJUnit4ClassRunner.

Entonces puedes hacer algo como esto:

public class NameAwareRunner extends BlockJUnit4ClassRunner {

    public NameAwareRunner(Class<?> aClass) throws InitializationError {
        super(aClass);
    }

    @Override
    protected Statement methodBlock(FrameworkMethod frameworkMethod) {
        System.err.println(frameworkMethod.getName());
        return super.methodBlock(frameworkMethod);
    }
}

Luego, para cada clase de prueba, deberá agregar una anotación @RunWith (NameAwareRunner.class). Alternativamente, puede poner esa anotación en una superclase de prueba si no desea recordarla cada vez. Esto, por supuesto, limita su selección de corredores, pero eso puede ser aceptable.

Además, puede tomar un poco de kung fu para obtener el nombre de la prueba actual del Runner y en su marco, pero esto al menos le da el nombre.

JUnit 4 no tiene ningún mecanismo listo para usar para que un caso de prueba obtenga su propio nombre (incluso durante la configuración y el desmontaje).

String testName = null;
StackTraceElement[] trace = Thread.currentThread().getStackTrace();
for (int i = trace.length - 1; i > 0; --i) {
    StackTraceElement ste = trace[i];
    try {
        Class<?> cls = Class.forName(ste.getClassName());
        Method method = cls.getDeclaredMethod(ste.getMethodName());
        Test annotation = method.getAnnotation(Test.class);
        if (annotation != null) {
            testName = ste.getClassName() + "." + ste.getMethodName();
            break;
        }
    } catch (ClassNotFoundException e) {
    } catch (NoSuchMethodException e) {
    } catch (SecurityException e) {
    }
}

Basado en el comentario anterior y considerando más, creé una extensión de TestWather que puedes usar en tus métodos de prueba JUnit con esto:

public class ImportUtilsTest {
    private static final Logger LOGGER = Logger.getLogger(ImportUtilsTest.class);

    @Rule
    public TestWatcher testWatcher = new JUnitHelper(LOGGER);

    @Test
    public test1(){
    ...
    }
}

La clase auxiliar de prueba es la siguiente:

public class JUnitHelper extends TestWatcher {
private Logger LOGGER;

public JUnitHelper(Logger LOGGER) {
    this.LOGGER = LOGGER;
}

@Override
protected void starting(final Description description) {
    LOGGER.info("STARTED " + description.getMethodName());
}

@Override
protected void succeeded(Description description) {
    LOGGER.info("SUCCESSFUL " + description.getMethodName());
}

@Override
protected void failed(Throwable e, Description description) {
    LOGGER.error("FAILURE " + description.getMethodName());
}
}

¡Disfrutar!

@ClassRule
public static TestRule watchman = new TestWatcher() {
    @Override
    protected void starting( final Description description ) {
        String mN = description.getMethodName();
        if ( mN == null ) {
            mN = "setUpBeforeClass..";
        }

        final String s = StringTools.toString( "starting..JUnit-Test: %s.%s", description.getClassName(), mN );
        System.err.println( s );
    }
};

Te sugiero que desacoples el nombre del método de prueba de tu conjunto de datos de prueba. Modelaría una clase DataLoaderFactory que carga / almacena en caché los conjuntos de datos de prueba de sus recursos, y luego en su caso de prueba puede llamar a algún método de interfaz que devuelve un conjunto de datos de prueba para el caso de prueba. Tener los datos de prueba vinculados al nombre del método de prueba supone que los datos de prueba solo se pueden usar una vez, donde en la mayoría de los casos sugeriría que los mismos datos de prueba se utilicen en múltiples pruebas para verificar varios aspectos de su lógica comercial.

Puede lograr esto usando Slf4jyTestWatcher

private static Logger _log = LoggerFactory.getLogger(SampleTest.class.getName());

@Rule
public TestWatcher watchman = new TestWatcher() {
    @Override
    public void starting(final Description method) {
        _log.info("being run..." + method.getMethodName());
    }
};

En JUnit 5 TestInfoactúa como un reemplazo directo para la regla TestName de JUnit 4.

De la documentación:

TestInfo se usa para inyectar información sobre la prueba o el contenedor actual en los métodos @Test, @RepeatedTest, @ParameterizedTest, @TestFactory, @BeforeEach, @AfterEach, @BeforeAll y @AfterAll.

Para recuperar el nombre del método de la prueba ejecutada actual, tiene dos opciones: String TestInfo.getDisplayName()y Method TestInfo.getTestMethod().

Para recuperar solo el nombre del método de prueba actual TestInfo.getDisplayName()puede no ser suficiente ya que el nombre para mostrar predeterminado del método de prueba es methodName(TypeArg1, TypeArg2, ... TypeArg3).
Duplicar nombres de métodos @DisplayName("..")no es necesariamente una buena idea.

Como alternativa, podría usar TestInfo.getTestMethod()eso que devuelve un Optional<Method>objeto.
Si el método de recuperación se usa dentro de un método de prueba, ni siquiera necesita probar el Optionalvalor ajustado.

import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.TestInfo;
import org.junit.jupiter.api.Test;

@Test
void doThat(TestInfo testInfo) throws Exception {
    Assertions.assertEquals("doThat(TestInfo)",testInfo.getDisplayName());
    Assertions.assertEquals("doThat",testInfo.getTestMethod().get().getName());
}

JUnit 5 a través de ExtensionContext

Ventaja:

Puede tener las funcionalidades adicionales de ExtensionContextanulando afterEach(ExtensionContext context).

public abstract class BaseTest {

    protected WebDriver driver;

    @RegisterExtension
    AfterEachExtension afterEachExtension = new AfterEachExtension();

    @BeforeEach
    public void beforeEach() {
        // Initialise driver
    }

    @AfterEach
    public void afterEach() {
        afterEachExtension.setDriver(driver);
    }

}

public class AfterEachExtension implements AfterEachCallback {

    private WebDriver driver;

    public void setDriver(WebDriver driver) {
        this.driver = driver;
    }

    @Override
    public void afterEach(ExtensionContext context) {
        String testMethodName = context.getTestMethod().orElseThrow().getName();
        // Attach test steps, attach scsreenshots on failure only, etc.
        driver.quit();
    }

}