I'm refactoring some test classes from TestNG to JUnit 4. During the process, I've stumbled upon the following annotations:
#BeforeTest
#AfterTest
According to the manual:
The annotated method will be run before/after any test method belonging to the classes inside the tag is run.
What would be the equivalent annotations in JUnit?
This is the original answer, but I think it is wrong. See below for a better one
The equivalent would be the annotations
#Before
and
#After
see also http://junit.sourceforge.net/javadoc/org/junit/Before.html
This is a better answer, after I learned about the difference between Before/AfterMethod and Before/AfterTest in TestNG
If I got it right, with Before/AfterTest you can run a method before or after a list of tests, that you specify inside the annotation or a separate document.
There is no out of the box feature like this in JUnit.
Probably the best you can do, is put what ever you want to do in a JUnit Rule. See also http://schauderhaft.de/2011/07/24/rules-in-junit-4-9-beta-3/
Then you can use that Rule in any test that needs it.
Related
What is the advantage to adding the #Disabled or #Ignore annotations to JUnit tests, e.g.:
#Test
#Disabled
void testSomething() { /* ... */ }
instead of just removing the #Test annotation?
void testSomething() { /* ... */ }
Either way, the test should not be executed.
The utility of these annotations is largely in documentation/reporting. When you run a JUnit suite, you get a report of the results. #Ignored/#Disabled tests will be marked as such (with optional comments) in that report.
This lets you track how many tests are being ignored/disabled. You can set policies around this (i.e. if a test is #Ignored for a month, just delete it) or make CI systems fail if too many tests are being #Ignored. You can make graphs showing trends of Passed/Failed/Skipped over time.
Really, it all comes down to how you want to track the evolution of your test suite, and wether you'd want to see a section of "skipped" tests, or the total number of tests going down when a test is temporarily broken/no longer useful.
#Disabled or #Ignore annotations can be used to disable or ignore the test methods from the test suite.
#Disabled introduced in junit5. It accepts only one optional parameter, which indicates the reason this test is disabled. Example :
#Disabled("Do not run in a lower environment")
Advantages of adding #Disabled or #Ignore:
Search-ability: You can easily identify all #Ignore or #Disabled annotations in the source code, while unannotated or commented out tests are not so simple to find.
Maintainable: It is easy to maintain or modify it later. It is always good practice to use annotations.
In my opinion, #Ignore is cleaner than commenting an entire block of test method .
Also, when you run your test suite, you would get a warning about some tests are ignored. You won’t get that if you comment it. That maybe someday you would want to enable it
Other advantages:
Manual-only execution: ensures a test is never run automatically while still allowing you to run it manually with no code change. My preferred approach for this, since it defaults to safe behaviour without requiring any configuration of test engine or test run.
Avoids warnings: untagging can trigger "unused code"-warnings for tests that are in use, only manually
Modularity: You can use it on an entire test class, whereas in JUnit 5 you would need to untag each test case individually
Is there a way to run JUnit programmatically in which I could pass custom PrintStream for all output of JUnit framework itself and leave standard output for test cases?
I see that JUnit internally is using JUnitSystem and TextListener to achieve this but I don't see intended entry point to use it without modifying or extending JUnitCore.
Does anyone have idea how to achieve this?
I don't think that JUnitCore and the classes used underneath print anything to standard out. The notable exception is JUnitCore.main, but this is just the main method for direct command-line execution. Instead you should use one of the run or runClasses methods. Your own RunListener can then output whatever/however it desires.
I'm currently working on a class, dealing with network issues. Using JUnit 3.8.1 and having a hardware device, that's not always around to test against, I'd like to conditionally suppress individual tests. Is there a way to achive this with a simple annotation like #if(!gatewayAvailable) -> test's suppressed?
Thanx for any pointers, marcus
There is no such feature in JUnit 3.8.1. You have to use JUnit4 and its Assume class.
I want to test validation logic in a legacy class. The class uses a method to load effective dates from a config file.
I have written a subclass of the class in question and overridden the config method so I can run my unit test against the subclass with any combination of effective dates.
Is this an appropriate strategy? It strikes me as a clean technique for testing code that you don't want to mess with.
I like it, its the most simple and straight forward way to get this done. And since it is a legacy class, it will not change anymore, so you don't run danger of bumping into the fragile base class problem neither.
It seems to be an appropriate strategy to me. Ofcourse with this override you won't
be able to test the code (in the original class) that loads the config data, but if you have other tests to cover this sceario then I think the approach you outlined is fine.
I'm trying to migrate to JUnit 4 and I'm not clear about the correct way to set up test suites.
I know how to set up a test suite with fixed tests using the #SuitesClasses annotation.
However, I want to have a top-level suite class, where I can programatically decide which test classes or suites I want to load. I know that there are addTest and addTestSuite operations in the TestSuite class.
However, if I define a TestSuite subclass with a constructor that attempts to add these tests and try to run it, I get an error "Must have SuiteClasses annotation".
Any idea how to do this?
I would recommend creating a subclass of the BlockJUnit4ClassRunner and pull in the classes you want to test manually. The protected methods of the class do all the hard work for you, although you might want to tweak the Descriptions a bit to make sure the results are all unique in the output files.