How to use TestCase class of junit.framework package

Using reflection, you can invoke a private constructor:

Constructor<Util> c = Utils.class.getDeclaredConstructor();
c.setAccessible(true);
Utils u = c.newInstance(); // Hello sailor

However, you can make even that not possible:

private Utils() {
    throw new UnsupportedOperationException();
}

By throwing an exception in the constructor, you prevent all attempts.

I would make the class itself final too, just "because":

public final class Utils {
    private Utils() {
        throw new UnsupportedOperationException();
    }
}

Make sure the hamcrest jar is higher on the import order than your JUnit jar.

JUnit comes with its own org.hamcrest.Matcher class that is probably being used instead.

You can also download and use the junit-dep-4.10.jar instead which is JUnit without the hamcrest classes.

mockito also has the hamcrest classes in it as well, so you may need to move\reorder it as well

I got around this by upgrading to the latest version of mockito. Currently it is:

testImplementation "org.mockito:mockito-core:2.25.1"

After that I had some build errors which was resolved by selecting

File->Invalidate Caches / Restart...

Try anyInt():

when(candidateService.findById(anyInt())).thenReturn(new Candidate());

For example I have anyLong() in my project:

when(dao.getAddress(anyLong())).thenReturn(Arrays.asList(dto));

EDIT: You must import:

import static org.mockito.Matchers.anyInt;

I think it's quite important feature for JUnit, if author of JUnit doesn't want the order feature, why?

I'm not sure there is a clean way to do this with JUnit, to my knowledge JUnit assumes that all tests can be performed in an arbitrary order. From the FAQ:

How do I use a test fixture?

(...) The ordering of test-method invocations is not guaranteed, so testOneItemCollection() might be executed before testEmptyCollection(). (...)

Why is it so? Well, I believe that making tests order dependent is a practice that the authors don't want to promote. Tests should be independent, they shouldn't be coupled and violating this will make things harder to maintain, will break the ability to run tests individually (obviously), etc.

That being said, if you really want to go in this direction, consider using TestNG since it supports running tests methods in any arbitrary order natively (and things like specifying that methods depends on groups of methods). Cedric Beust explains how to do this in order of execution of tests in testng.

Have you studied Testing chapter in Spring reference documentation? Here is an example you should start with:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class MyTest {

    @Resource
    private FooService fooService;

    // class body...
}

If you are in com.example.MyTest in /src/test/java, you will need /src/test/resources/com/example/MyTest-context.xml - but the exceptions will show you the way.

It really depends on GeneralConfigService#getInstance() implementation. Also you can simplify your test code a lot if you use @InjectMocks annotation.

When using MockitoJUnitRunner you don't need to initialize mocks and inject your dependencies manually:

@RunWith(MockitoJUnitRunner.class)
public class GeneralConfigServiceImplTest  {

    @InjectMocks
    private GeneralConfigService generalConfigService;

    @Mock
    private GeneralConfigDAO generalConfigDAO;

    @Test
    public void testAddGeneralConfigCallDAOSuccess() {
       // generalConfigService is already instantiated and populated with dependencies here
       ...
    }
}

Take a look at Parameterized Tests in JUnit 4.

Actually I did this a few days ago. I'll try to explain ...

First build your test class normally, as you where just testing with one input file. Decorate your class with:

@RunWith(Parameterized.class)

Build one constructor that takes the input that will change in every test call (in this case it may be the file itself)

Then, build a static method that will return a Collection of arrays. Each array in the collection will contain the input arguments for your class constructor e.g. the file. Decorate this method with:

@Parameters

Here's a sample class.

@RunWith(Parameterized.class)
public class ParameterizedTest {

    private File file;

    public ParameterizedTest(File file) {
        this.file = file;
    }

    @Test
    public void test1() throws Exception {  }

    @Test
    public void test2() throws Exception {  }

    @Parameters
    public static Collection<Object[]> data() {
        // load the files as you want
        Object[] fileArg1 = new Object[] { new File("path1") };
        Object[] fileArg2 = new Object[] { new File("path2") };

        Collection<Object[]> data = new ArrayList<Object[]>();
        data.add(fileArg1);
        data.add(fileArg2);
        return data;
    }
}

Also check this example

You could use a pattern as well, for example

 mvn '-Dtest=de.mypackage.*Test' test

runs all tests in classes from package de.mypackage ending on *Test.

[update 2017/12/18]:
Since this became the accepted answer, here's some further information:

• Maven uses the Maven Surefire plugin to execute tests.

• The syntax used above (qualified package name) requires Surefire version 2.19.1 or higher! Earlier versions require the use of path expressions, for example

  mvn -Dtest="de/mypackage/*Test" test
  

• I'm using quotes (` or ") to prevent the shell from performing pathname expansion, Maven doesn't require any quotes.

• A single test method can be exuted using the following syntax

  mvn -Dtest=MyUnitTest#testMethod test
  

• All tests from subpackages may be includes as well, in order to execute all tests in or beneath package de.mypackage.sub execute:

  mvn -Dtest="de/mypackage/sub/**" test
  

  or with Surefire 2.19.1 or higher

  mvn -Dtest="de.mypackage.sub.**" test
  

There are further possibilities like using regular expressions, see the official documentation of running a single test.