How to use anyOf method of org.hamcrest.CoreMatchers class

Spring uses commons-logging which auto-detects the logging framework to use. There are various ways to tune which logging framework will be chosen so the first thing to do is to make sure commons-logging binds to log4j.

To do that, start your application with an additional flag -Dorg.apache.commons.logging.diagnostics.dest=STDOUT that will output the result of the discovery process.

commons-logging delegate to log4j

You now need to make sure that log4j is initialise with the expected configuration. By default, log4j searches for a log4j.xml file at the root of the classpath and fallbacks to log4j.properties if it does not find one. It could be possible that one of the library you are using has (wrongly) a log4j.xml file at the root.

To debug log4j, run your application again with an additional flag -Dlog4j.debug=true. This will output the exact loggers and the location of the configuration file.

commons-logging does not delegate to log4j

If commons-logging does not delegate to log4j, this means that another logging framework is involved. The most common scenario is that your application ships with jcl-over-slf4j.jar, a drop-in replacement of commons-logging that uses slf4j behind the scene.

In this scenario, Spring uses commons-logging that is configured to delegate to slf4j. So, essentially, Spring is using slf4j. But slf4j is a simple logging facade and needs a binding to an actual framework.

SINCE 1.6.0 If no binding is found on the class path, then SLF4J will default to a no-operation implementation.

Once you have found the binding library (it could be logback or log4j for instance), check the configuration of the logging framework that slf4j is bound to.

In this particular case, you probably have logback in your classpath. As it is a pure implementation of slf4j, it does not need a binding library and it logs in debug if no configuration file is provided, which matches your problem actually. To fix your issue, exclude logback from your dependencies and add slf4j-log4j12 to configure slf4j with log4j.

Edit: updated with various comments

Declare a parameter of type TestInfo in your test method and JUnit will automatically supply an instance of that for the method:

@Test
void getTestInfo(TestInfo testInfo) { // Automatically injected
    System.out.println(testInfo.getDisplayName());
    System.out.println(testInfo.getTestMethod());
    System.out.println(testInfo.getTestClass());
    System.out.println(testInfo.getTags());
}

You can get test method name (and more) from the TestInfo instance as shown above.

Yes, all three methods will run within the same transaction. See section TestContext Framework/Transaction management in the reference docs:

Any before methods (such as methods annotated with JUnit's @Before) and any after methods (such as methods annotated with JUnit's @After) are executed within a transaction

Thus the @Transactional annotation on mySetup() and myTeardown() is kind of redundant, or might be even considered misleading, as their transactionality is determined by the individual test method being currently executed.

This is because the beforeTestMethod() and afterTestMethod() callbacks of TransactionalTestExecutionListener (responsible for starting/completing the transaction) are executed before JUnit's @Before and after JUnit's @After methods, respectively.

There is no automated uninstaller.

You have to remove Eclipse manually by deleting some directories and files.

Note: I use Unix style paths in this answer but the locations should be the same on Windows or Unix systems, so ~ refers to the user home directory even on Windows.

Why is there no uninstaller?

According to this discussion about uninstalling Eclipse, the reasoning for not providing an uninstaller is that the Eclipse installer is supposed to just automate a few tasks that in the past had to be done manually (like downloading and extracting Eclipse and adding shortcuts), so they also can be undone manually. On Windows there is no entry in "Programs and Features" because the installer does not register installations in the system registry.

How to to locate Eclipse installations

The default installation path is in `~/eclipse/.

The Eclipse installer also keeps track of installations. Launch the installer and then open the "Bundle Pool" dialog (in simple mode it's in the menu - in advanced mode it's a small button next to the bundle pool drop down). You'll see list of "profiles". Double click on a profile to see the path of the installation.

How to quickly uninstall Eclipse

If you have installed Eclipse manually without the Eclipse installer, just delete the Eclipse directory and be done with it.

If you have installed Eclipse with the Eclipse installer, then delete the Eclipse directory and any desktop and start menu shortcuts. Then launch the Eclipse installer and open the "Bundle Pool" dialog and click on "Cleanup Agent" to remove unused bundles. This won't affect other Eclipse installations if you have any.

In my opinion this is generally enough and I would stop here

How to completely uninstall Eclipse

If you really want to remove Eclipse without leaving any traces, you have to manually delete

• all desktop and start menu shortcuts
• all installation directories (e.g. ~/eclipse/photon/)
• the p2 bundle pool (which is often shared with other eclipse installations)

The installer has a "Bundle Pools" menu entry which lists the locations of all bundle pools. If you have other Eclipse installations on your system you can use the "Cleanup Agent" to remove unused bundles. If you don't have any other Eclipse installations you can delete the whole bundle pool directory instead (by default ~/p2/).

If you want to completely remove the Eclipse installer too, delete the installer's executable and the ~/.eclipse/ directory.

Depending on what kind of work you did with Eclipse, there can be more directories that you may want to delete. If you used Maven, then ~/.m2/ contains the Maven cache and settings (shared with Maven CLI and other IDEs). If you develop Eclipse plugins, then there might be JUnit workspaces from test runs, next to you Eclipse workspace. Likewise other build tools and development environments used in Eclipse could have created similar directories.

How to delete all projects

If you want to delete your projects and workspace metadata, you have to delete your workspace(s). The default workspace location is ´~/workspace/´. You can also search for the .metadata directory to get all Eclipse workspaces on your machine.

If you are working with Git projects, these are generally not saved in the workspace but in the ~/git/ directory.

Addendum: Windows Registry

Even though Eclipse isn't "installed" like a regular Windows application, there are still a few entries that get written to the system registry. If you search the Registry for "eclipse" you'll likely find some entries for URL handlers named eclipse+command, eclipse+mpc or eclipse+installer. They are used e.g. for letting you install Eclipse plugins from the browser.

On my system I see a few other entries which I believe are created by Windows itself and not by Eclipse (e.g. entries in the list of recently used executables). Whether you want to delete those entries is up to you. Personally I wouldn't, but on the other hand it probably won't break anything if you do. Just be aware that registry "cleaning" is a controversial topic.

In Junit5, There are options for configuring or run the test for specific Operating System.

@EnabledOnOs({ LINUX, MAC })
void onLinuxOrMac() {

}

@DisabledOnOs(WINDOWS)
void notOnWindows() {
    // ...
}

EDIT: With the recently released Junit 4.10, you can use RuleChain to chain rules correctly (see at the end).

You could introduce another private field without the @Rule annotation, then you can reorder your code as you wish:

public class FolderRuleOrderingTest {

    private TemporaryFolder privateFolder = new TemporaryFolder();

    @Rule
    public MyNumberServer server = new MyNumberServer(privateFolder);

    @Rule
    public TemporaryFolder folder = privateFolder;

    @Test
    public void testMyNumberServer() throws IOException {
        server.storeNumber(10);
        assertEquals(10, server.getNumber());
    }
    ...
}

The cleanest solution is to have a compound rule, but the above should work.

EDIT: With the recently released Junit 4.10, you can use RuleChain to chain rules correctly:

public static class UseRuleChain {
   @Rule
   public TestRule chain = RuleChain
                          .outerRule(new LoggingRule("outer rule"))
                          .around(new LoggingRule("middle rule"))
                          .around(new LoggingRule("inner rule"));

   @Test
   public void example() {
           assertTrue(true);
   }
}

writes the log

starting outer rule
starting middle rule
starting inner rule
finished inner rule
finished middle rule
finished outer rule

Can I recommend doing it this way, define your test like this:

@RunWith(SpringJUnit4ClassRunner.class)
@TestExecutionListeners({
    TestPreperationExecutionListener.class
    })
@Transactional
@ActiveProfiles(profiles = "localtest")
@ContextConfiguration
public class TestContext {

  @Test
  public void testContext(){

  }

  @Configuration
  @PropertySource("classpath:/myprops.properties")
  @ImportResource({"classpath:context.xml" })
  public static class MyContextConfiguration{

  }
}

with the following content in myprops.properties file:

spring.profiles.active=localtest

With this your second properties file should get resolved:

META-INF/spring/config_${spring.profiles.active}.properties

In JUnit, Parameterized tests use a special runner that ensure that the test is instantiated multiple times, so each test method is called multiple times. Mockito is a tool for writing specific unit tests, so there is no built-in ability to run the same test multiple times with different Mockito expectations.

If you want your test conditions to change, your best bet is to do one of the following:

• Parameterize your test using JUnit, with a parameter for the mock inputs you want;
• Run a loop of different parameters in your test, which unfortunately avoids the "test one thing per method" philosophy
• Extract a method that actually performs the test, and create a new @Test method for each mock you want.

Note that there's no prohibition on using mock objects as @Parameterized test parameters. If you're looking to parameterize based on mocks, you can do that, possibly creating the mock and setting the expectations in a static method on the test.

Note about runners: This Parameterized test runner conflicts with Mockito's MockitoJUnitRunner: Each test class can only have one runner. You'll want to switch to @Before and @After methods or a Mockito JUnit4 rule for your setup, if you use them both.

As an example, compressed from a different answer that explains more about Parameterized runners versus JUnit rules and lifting from the JUnit4 Parameterized Test doc page and MockitoRule doc page:

@RunWith(Parameterized.class)
public class YourComponentTest {
    @Rule public MockitoRule rule = MockitoJUnit.rule();
    @Mock YourDep mockYourDep;

    @Parameters public static Collection<Object[]> data() { /* Return the values */ }

    public YourComponentTest(Parameter parameter) { /* Save the parameter to a field */ }

    @Test public void test() { /* Use the field value in assertions */ }
}

do we use private methods only for program logic and not for program security?

It is not clear what you mean by "program security". Security cannot be discussed in a vacuum; what resources are you thinking of protecting against what threats?

The CLR code access security system is intended to protect resources of user data from the threat of hostile partially trusted code running on the user's machine.

The relationship between reflection, access control and security in the CLR is therefore complicated. Briefly and not entirely accurately, the rules are these:

• full trust means full trust. Fully trusted code can access every single bit of memory in the process. That includes private fields.

• The ability to reflect on privates in partial trust is controlled by a permission; if it is not granted then partial trust code may not do reflection on privates.

See http://blogs.msdn.com/b/shawnfa/archive/2006/09/29/777047.aspx for details.

• The desktop CLR supports a mode called "restricted skip visibility" in which the rules for how reflection and the security system interact are slightly different. Basically, partially trusted code that has the right to use private reflection may access a private field via reflection if the partially trusted code is accessing a private field from a type that comes from an assembly with equal or less trust.

See

http://blogs.msdn.com/b/shawnfa/archive/2006/10/05/using-lightweight-codegen-from-partial-trust.aspx

for details

The executive summary is: you can lock partially trusted code down sufficiently that it is not able to use reflection to look at private stuff. You cannot lock down full trust code; that's why it's called "full trust". If you want to restrict it then don't trust it.

So: does making a field private protect it from the threat of low trust code attempting to read it, and thereby steal user's data? Yes. Does it protect it from the threat of high trust code reading it? No. If the code is both trusted by the user and hostile to the user then the user has a big problem. They should not have trusted that code.

Note that for example, making a field private does not protect a secret in your code from a user who has your code and is hostile to you. The security system protects good users from evil code. It doesn't protect good code from evil users. If you want to make something private to keep it from a user then you are on a fool's errand. If you want to make it private to keep a secret from evil hackers who have lured the user into running hostile low-trust code then that is a good technique.