W JUnit 3 mogłem uzyskać nazwę aktualnie uruchomionego testu w następujący sposób:

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

które wyświetliłoby komunikat „Bieżący test to test”.

Czy w JUnit 4 jest jakaś gotowa lub prosta metoda?

Tło: Oczywiście nie chcę po prostu drukować nazwy testu. Chcę załadować dane specyficzne dla testu, które są przechowywane w zasobie o tej samej nazwie co test. Wiesz, konwencja o konfiguracji i tak dalej.

JUnit 4.7 dodał tę funkcję, korzystając z reguły TestName . Wygląda na to, że otrzymasz nazwę metody:

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.xi wyższe

Od JUnit 4.9 TestWatchmanklasa jest przestarzała na rzecz TestWatcherklasy, która ma wywołanie:

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

Uwaga: Klasa zawierająca musi zostać zadeklarowana public.

JUnit 4.7.x - 4.8.x

Następujące podejście wypisze nazwy metod dla wszystkich testów w klasie:

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

JUnit 5 i nowszy

W JUnit 5 możesz wstrzykiwać, TestInfoco upraszcza metadane testowe zapewniające metody testowe. Na przykład:

@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"));
}

Zobacz więcej: Podręcznik użytkownika JUnit 5 , TestInfo javadoc .

Spróbuj zamiast tego:

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());
        }
}

Dane wyjściowe wyglądają następująco:

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

UWAGA: To NIE DZIAŁA, jeśli twój test jest podklasą TestCase ! Test działa, ale kod @Rule po prostu nigdy nie działa.

Zastanów się nad użyciem SLF4J (Simple Logging Facade for Java) zapewnia pewne udoskonalenia za pomocą sparametryzowanych komunikatów. Połączenie SLF4J z implementacjami reguł JUnit 4 może zapewnić bardziej wydajne techniki rejestrowania klas testów.

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() {

  }
}

Skręconym sposobem jest utworzenie własnego Runnera przez podklasowanie org.junit.runners.BlockJUnit4ClassRunner.

Następnie możesz zrobić coś takiego:

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);
    }
}

Następnie dla każdej klasy testowej musisz dodać adnotację @RunWith (NameAwareRunner.class). Ewentualnie możesz umieścić tę adnotację w nadklasie testowej, jeśli nie chcesz jej pamiętać za każdym razem. To oczywiście ogranicza wybór biegaczy, ale może to być do zaakceptowania.

Może również zająć trochę kung fu, aby pobrać bieżącą nazwę testową z Runnera do twojego frameworka, ale to przynajmniej zapewni ci nazwę.

JUnit 4 nie ma gotowego mechanizmu do testowania, aby uzyskać własną nazwę (w tym podczas instalacji i porzucenia).

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) {
    }
}

W oparciu o poprzedni komentarz i dalsze rozważania stworzyłem rozszerzenie TestWather, którego można użyć w metodach testowych JUnit za pomocą tego:

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

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

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

Klasa pomocnika testowego jest następna:

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());
}
}

Cieszyć się!

@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 );
    }
};

Proponuję oddzielić nazwę metody testowej od zestawu danych testowych. Modelowałbym klasę DataLoaderFactory, która ładuje / buforuje zestawy danych testowych z twoich zasobów, a następnie w twoim przypadku testowym kamera wywołuje metodę interfejsu, która zwraca zestaw danych testowych dla przypadku testowego. Powiązanie danych testowych z nazwą metody testowej zakłada, że ​​danych testowych można użyć tylko raz, w większości przypadków sugerowałbym, aby te same dane testowe były używane w wielu testach w celu weryfikacji różnych aspektów logiki biznesowej.

Możesz to osiągnąć za pomocą Slf4jiTestWatcher

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());
    }
};

W JUnit 5 TestInfo działa jako drop-in zamiennik reguły TestName z JUnit 4.

Z dokumentacji:

TestInfo służy do wstrzykiwania informacji o bieżącym teście lub pojemniku do metod @Test, @RepeatedTest, @ParameterizedTest, @TestFactory, @BeforeEach, @AfterEach, @BeforeAll i @AfterAll.

Aby pobrać nazwę metody aktualnie wykonywanego testu, masz dwie opcje: String TestInfo.getDisplayName()i Method TestInfo.getTestMethod() .

Aby pobrać tylko nazwę bieżącej metody testowej, TestInfo.getDisplayName()może nie wystarczyć, ponieważ domyślna nazwa wyświetlana metody testowej to methodName(TypeArg1, TypeArg2, ... TypeArg3).
Powielanie nazw metod w@DisplayName("..") nie jest koniecznym dobrym pomysłem.

Alternatywnie możesz użyć TestInfo.getTestMethod()zwracającego Optional<Method>obiekt.
Jeśli metoda pobierania jest używana w metodzie testowej, nie trzeba nawet testować Optionalopakowanej wartości.

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 przez ExtensionContext

Korzyść:

Możesz mieć dodatkowe funkcje ExtensionContextzastępowania 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();
    }

}