Junit beforeall не работает

Junit5- jupiter all tests suite @BeforeAll @AfterAll not working

The before and after methods not working in JUnitPlatform.

The code is below.

I just want to running before and after methods.

2 Answers 2

I may cite the JUnit 5 migration tipps:

@Before and @After no longer exist; use @BeforeEach and @AfterEach instead.

@BeforeClass and @AfterClass no longer exist; use @BeforeAll and @AfterAll instead.

But these annotations should be used in your test class. The methods in your suite class will not be invoked this way. And you should be aware of the fact that suites and JUnit 5 are still work in progress (see Issue 744).

You may want to check that org.junit.jupiter:junit-jupiter-engine is in your classpath.

However, recent versions of build tools (Maven with surefire plugin, Gradle, Eclipse, IntelliJ, etc.) support junit-platform. Therefore you do not need to use JUnit4 with a backward-compatible runner.

Usually you can be in the following cases:

creating new project, in which case you can start directly using only JUnit-Jupiter (and without having JUnit4 in your classpath)

migrating a project from JUnit4 to JUnit5. Here you will want to have two engines: JUnit-Vintage, which covers retrocompatibility for existing tests using the JUnit4 API, and JUnit-Jupiter who offer more flexibility, including the composition of extensions (having Spring, Mockito and parameterized tests features at the same time)

Using a JUnit4 runner to run JUnit-Jupiter tests is really a corner case, when you are constrained by an environment (build tool and/or IDE) that you cannot change.

For more details, sample projects are made available by the JUnit team:

Источник

Document that @BeforeAll & @AfterAll are unsupported in @Nested test classes #88

Comments

sbrannen commented Jan 5, 2016

Status Quo

Since support for configuring the test instance lifecycle was dropped after the prototype, @BeforeAll and @AfterAll methods are now required to be static . Consequently such methods can no longer be used in @Nested test classes. Any attempt to do so will result in a compilation error similar to the following.

The method myBeforeAllMethod cannot be declared static; static methods can only be declared in a static or top level type.

See the nested test classes in com.example.HierarchyTestCase for concrete examples.

Deliverables

• Decide how to handle @BeforeAll and @AfterAll methods in nested test classes.
  • The team decided that this is simply not supported since the Java language doesn’t support it.
• Document that @BeforeAll and @AfterAll are unsupported in nested test classes.
• Delete com.example.HierarchyTestCase .

The text was updated successfully, but these errors were encountered:

sbrannen commented Jan 5, 2016

@junit-team/junit-lambda, this is a gotcha that we will need to discuss amongst the group.

jlink commented Jan 5, 2016

I see several options. No need for desperation 😉

The simplest thing might just be to disallow @Before/AfterAll in nested tests since nested tests IMO are a means to group tests by their domain context not by their technical context. If someone really really needs a before/afterAll for technical reasons, they can easily use an extension.

sbrannen commented Jan 20, 2016

Resolve in master . See associated commits for details.

mkobit commented Jul 7, 2016

After reading through this and trying to look at the other issues, does it still make sense that @BeforeAll and @AfterAll have to be static ?

sbrannen commented Jul 10, 2016

Without «test instance per test class» semantics it is required that @BeforeAll and @AfterAll methods be static . See the description of #48 for details.

However, once #48 is resolved, the static restriction will possibly be removed for scenarios in which that makes sense.

silkentrance commented Jan 30, 2018 •

@sbrannen a valid position against @BeforeAll and @AfterAll being static would be the Spring Framework or any such framework that provides for dependency injection of either configuration or components or services used during the tests.

And, considering that during @BeforeAll one would establish a required set of data (aka fixtures) in for example a database, one cannot accomplish that when using static methods unless one would set up a spring ioc before hand and use that only for the purpose of the @BeforeAll and @AfterAll , aka the test set up and tear down methods.

I know there exists the SpringExtension, however, this only works on the test instance, and the static versions of both @BeforeAll and @AfterAll are not supported here.

silkentrance commented Jan 30, 2018 •

@sbrannen and i do not see why we would need the Scenario abstraction as proposed by #48. the latter seems to be a poor man’s implementation of what cucumber already provides. And we do not need such functionality in the core.

The main reason for @Before/AfterAll are still static is the fact that on instance level one will override existing behaviour inherited from a base test class, e.g.

So here, the concrete test class’ setUp method will override the base test class’ method.
Why not use standard java idioms here? Allow the derived class to either call upon super or simply override its behaviour.

And given the new feature of nested tests, why not extend this feature to nested tests also?
Having both instance level @Before/AfterAll and static versions of both?

Traversing the inheritance hierarchy from top to bottom first, level by level, resolving all static versions of @BeforeAll , and, on each level, allowing the user to establish a breadth first resolve of the @BeforeAll on instance level by calling super or not. The same with @AfterAll on both static methods and instance methods, again allowing the user to call upon super or not, however this time it will resolve the @AfterAll from the lowest level in the inheritance hierarchy, traversing upwards.

And this should also encompass extensions, which would then always provide their @Before/AfterAll s on a static level.

And if the user messes up, who cares? Either they get it or they don’t.

So, in the above example, the before all / after all would be called in the following fashion

Having such a feature will allow us to use auto wired instances of either configurations a/o services a/o components during both instance level tear down and set up without us having to provide for such mechanisms at the static level, requiring additional and mostly redundant code.

Источник

In JUnit 5, how to run code before all tests

The @BeforeAll annotation marks a method to run before all tests in a class.

But is there a way to run some code before all tests, in all classes?

I want to ensure that tests use a certain set of database connections, and the global one-time setup of these connections must occur before running any tests.

7 Answers 7

This is now possible in JUnit5 by creating a custom Extension, from which you can register a shutdown hook on the root test-context.

Your extension would look like this;

Then, any tests classes where you need this executed at least once, can be annotated with:

When you use this extension on multiple classes, the startup and shutdown logic will only be invoked once.

The already provided answer from @Philipp Gayret has some problems when testing JUnit in parallel (i.e. junit.jupiter.execution.parallel.enabled = true ).

Therefore I adapted the solution to:

As mentioned below JUnit5 provides an automatic Extension Registration. To do so add a in src/test/resources/ a directory called /META-INF/services and add a file named org.junit.jupiter.api.extension.Extension . Add into this file the fully classified name of your class, e.g.

Next enable in the same Junit config file

With this the extension is attached automatically to all of your tests.

Extending on suggestion from @Philipp, here’s a more complete code snippet:

Test execution order will be:

. this will be true regardless if you choose to run a single @Test (e.g. TestOne.testOne), or an entire test class (TestOne), or multiple / all tests.

You can mark each of your test classes that uses your database with an interface that defines a static BeforeAll (so that it cannot be overridden). e.g.:

This method will be invoked once for each implementing class so you will need to define a way to initialize your connections only once and then do nothing for the other calls.

I am not aware of a mean to do that.

I would simply make sure that all code for @BeforeAll calls a certain singleton to make that init work (probably in a lazy way to avoid repetition).

Probably not convenient . the only other option I see: I assume your tests run within a specific JVM job. You could hook an agent into that JVM run, that does that init work for you.

Beyond that: both suggestions sounds somehow like a hack to me. The real answer in my eyes: step back, and carefully examine your environment on its dependencies. And then find a way to prepare your environment in a way that your tests come up and the «right thing» happens automatically. In other words: consider looking into the architecture that bought you this problem.

Источник

Test not failing if BeforeAll crashes #2178

Comments

hheg commented Feb 10, 2020 •

Junit 5.4.2 and 5.6.0
Attached a failing example

Rationale expected:
If a BeforeAll method crashes, the test should be reported as failed

Actual
Tests are silently ignored and the result is success.

Steps to reproduce

Create a maven project with Junit 5 as test runner
Create a test with a BeforeAll method which throws an RuntimeException
See that the tests passes. Example below

Context

• Used versions (Jupiter/Vintage/Platform):
  5.6.0//1.6.0
• Build Tool/IDE:
  Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
  openjdk 11.0.6 2020-01-14
  OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.6+10)
  OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.6+10, mixed mode)
  and
  openjdk version «1.8.0_242»
  OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_242-b08)
  OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.242-b08, mixed mode)

Deliverables

The text was updated successfully, but these errors were encountered:

sormuras commented Feb 10, 2020

Didn’t look into the attached project, yet, but it seems that Surefire didn’t launch the JUnit Platform. Thus, all methods with JUnit Jupiter annotations weren’t invoked. Can you please run Maven with the -X parameter and post the Surefure part of the log here?

pzygielo commented Feb 10, 2020

It works fine with surefire 3.0.0-M3, and fails as described by author in M4 indeed. Probably SUREFIRE-1688.

hheg commented Feb 10, 2020

It works fine with surefire 3.0.0-M3, and fails as described by author in M4 indeed. Probably SUREFIRE-1688.

That bug fix is included in M4. Perhaps this use case broke when they fixed the assertion mechanics with SUREFIRE-1688?

hheg commented Feb 10, 2020

Didn’t look into the attached project, yet, but it seems that Surefire didn’t launch the JUnit Platform. Thus, all methods with JUnit Jupiter annotations weren’t invoked. Can you please run Maven with the -X parameter and post the Surefure part of the log here?

hheg commented Feb 10, 2020

Running without the exception in the BeforeAll method does invoke the tests like this:

pzygielo commented Feb 10, 2020

It works fine with surefire 3.0.0-M3, and fails as described by author in M4 indeed. Probably SUREFIRE-1688.

That bug fix is included in M4.

But check comment and comment to not be misled by status & fixed version.

sormuras commented Feb 10, 2020 •

Added another comment to the ticket and reopened it.

sormuras commented Feb 12, 2020

@hheg can you please use the latest-and-greatest version of Surefire, namely its SNAPSHOT build?

According to this comment and the following one, this issue already fixed.

hheg commented Feb 12, 2020

I can confirm that the bug is indeed resolved with the latest 3.0.0-SNAPSHOT 873da2808

sormuras commented Feb 12, 2020

Thus closing this issue as Surefire 3.0.0-M5 will be released . soon, I guess.

If there’s a regression, please report further issues at the Apache Maven issue tracker.

ksiddu commented Apr 1, 2020 •

@sormuras ,
Is there any way to fail the test cases(methods with @test tag) when @BeforeAll setup method fails.
I have two test cases in one test class with @BeforeAll and @afterall,
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] FirstTest.beforeAllFirstTest:23 expected: but was:
[INFO]
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0

How can i mark those 2 test cases as failed if the @BeforeAll method fails

Tibor17 commented Apr 19, 2020

I found that the problem is not with the resolution of the artifacts in the POM. In the issue SUREFIRE-1688 we fixed very similar problem where the AssertionError was throws in BeforeAll method. Here we throw the RuntimeException in the same method and we get zero total tests which is the bug. So it looks like these two exceptions are handled differently in Surefire.

cobbce commented Apr 20, 2020

Experiencing the same problem in which a runtime exception shows as 0 tests run— any resolution on when a fix will be available. Pretty terrifying when your test runner silently fails.

marcphilipp commented Apr 21, 2020

@Tibor17 If I understand you correctly, you’re saying this issue might not be fixed by https://issues.apache.org/jira/browse/SUREFIRE-1688? If so, @ksiddu or @cobbce, please report a new issue on Surefire’s issue tracker.

Tibor17 commented Apr 21, 2020 •

@marcphilipp To be more concrete, the analysis showed me that the sources of the IT for 1688 and the sources junit_fail.zip in this GH bug are the same except the type of thrown exception. In the IT 1688 we call fail(«some text») and here we throw RuntimeException . I have to debug our code to be more concrete because i also do not know more yet.

Tibor17 commented Apr 21, 2020 •

@ksiddu @cobbce Don’t open Jira in the Apache. We have it and i will debug the code which may result in closing our issue and reopening the old one or keeping it, or it is JUnit5 bug. But now nobody knows this.

Tibor17 commented Apr 21, 2020 •

This issue was handled in Apache JIRA and closed as a duplicate and not reproducible.
Not reproducible after re-testing with the latest SNAPSHOT version.
This was fixed with in SUREFIRE-1688 and SUREFIRE-1741 .

noguespi commented May 7, 2020

This issue was handled in Apache JIRA and closed as a duplicate and not reproducible.
Not reproducible after re-testing with the latest SNAPSHOT version.
This was fixed with in SUREFIRE-1688 and SUREFIRE-1741 .

Fixed for you, but not for us 🤷‍♂️
I’m affected by this bug on the latest stable release (3.0.0-M4). Downgrading didn’t fix the issue.

My ugly hack to fix the bug :
try/catch in beforeAll and System.exit(1) on exception.

silh commented Nov 6, 2020

Still having the same issue with 3.7.0.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник