How to use processArguments method of junit.runner.BaseTestRunner class

1. You can clear the data by dropping the schema. The default schema is called PUBLIC. If you execute the SQL satement below, it will clear all data and drop all tables.

   DROP SCHEMA PUBLIC CASCADE

2. Alternatively, if you need the table and schema object definitions, you can create a file: database containing the objects but no data, and add the property below to the .properties file. Using this type of database for tests, the changes to data are not persisted

   files_read_only=true

3. The latest alternative, available in HSQLDB 2.2.6 and later allows you to clear all the data in a schema while keeping the tables. In the example below, the PUBLIC schema is cleared.

   TRUNCATE SCHEMA public AND COMMIT

   This statement has been enhanced in the latest versions of HSQLDB. See http://hsqldb.org/doc/2.0/guide/dataaccess-chapt.html#dac_truncate_statement under Truncate Statement

I've gotten through the issue! Once I figured it out, I remember that this has happened before. I cleared all my breakpoints and it works fine. I have no idea why that would cause the outcome that is does, but it works.

Yes, it is possible. The easiest way for me at least is to add a test suite class. It can look like this:

package tests;

import org.junit.runner.RunWith;
import org.junit.runners.Suite;
import org.junit.runners.Suite.SuiteClasses;

import tests.message.ATest;
import tests.validator.BTest;
import tests.validator.CTest;
import tests.validator.DTest;

@RunWith(Suite.class)
@SuiteClasses({ ATest.class, 
        BTest.class, 
        CTest.class, 
        DTest.class })
public class AllTests {

}

This will allow you to test any class that you import no matter what package it is in. To run this in eclipse you just right click the AllTests class and run it as JUnit test. It will then run all the tests you define in @SuiteClasses.

This will work with linked sources as well, I use it all the time.

The Slf4j API doesn't provide such a way but Logback provides a simple solution.

You can use ListAppender : a whitebox logback appender where log entries are added in a public List field that we could use to make our assertions.

Here is a simple example.

Foo class :

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class Foo {

    static final Logger LOGGER = LoggerFactory.getLogger(Foo .class);

    public void doThat() {
        logger.info("start");
        //...
        logger.info("finish");
    }
}

FooTest class :

import org.slf4j.LoggerFactory;
import ch.qos.logback.classic.Level;
import ch.qos.logback.classic.Logger;
import ch.qos.logback.classic.spi.ILoggingEvent;
import ch.qos.logback.core.read.ListAppender;

public class FooTest {

    @Test
    void doThat() throws Exception {
        // get Logback Logger 
        Logger fooLogger = (Logger) LoggerFactory.getLogger(Foo.class);

        // create and start a ListAppender
        ListAppender<ILoggingEvent> listAppender = new ListAppender<>();
        listAppender.start();

        // add the appender to the logger
        fooLogger.addAppender(listAppender);

        // call method under test
        Foo foo = new Foo();
        foo.doThat();

        // JUnit assertions
        List<ILoggingEvent> logsList = listAppender.list;
        assertEquals("start", logsList.get(0)
                                      .getMessage());
        assertEquals(Level.INFO, logsList.get(0)
                                         .getLevel());

        assertEquals("finish", logsList.get(1)
                                       .getMessage());
        assertEquals(Level.INFO, logsList.get(1)
                                         .getLevel());
    }
}

You can also use Matcher/assertion libraries as AssertJ or Hamcrest.

With AssertJ it would be :

import org.assertj.core.api.Assertions;

Assertions.assertThat(listAppender.list)
          .extracting(ILoggingEvent::getFormattedMessage, ILoggingEvent::getLevel)
          .containsExactly(Tuple.tuple("start", Level.INFO), Tuple.tuple("finish", Level.INFO));

If you are testing [Unit Test] for the method methodToBeTested, you should simply mock routingservice.
You shouldn't be testing any methods that methodToBeTested calls.

However, it sounds like you want to test the RoutingService (you said "The problem is that RoutingService changes the state of objectToRoute and this is exactly what I want to check").

To test RoutingService methods, you should write separate unit tests for those methods.

Use PowerMockito on top of Mockito.

Example code:

@RunWith(PowerMockRunner.class)
@PrepareForTest(DriverManager.class)
public class Mocker {

    @Test
    public void shouldVerifyParameters() throws Exception {

        //given
        PowerMockito.mockStatic(DriverManager.class);
        BDDMockito.given(DriverManager.getConnection(...)).willReturn(...);

        //when
        sut.execute(); // System Under Test (sut)

        //then
        PowerMockito.verifyStatic();
        DriverManager.getConnection(...);

    }

More information:

• Why doesn't Mockito mock static methods?

I can think of several options:

• Finding out how much memory your method requires via a microbenchmark (i.e. jmh).
• Building allocation strategies based on heuristic estimation. There are several open source solutions implementing class size estimation i.e. ClassSize. A much easier way could be utilizing a cache which frees rarely used objects (i.e. Guava's Cache). As mentioned by @EnnoShioji, Guava's cache has memory-based eviction policies.

You can also write your own benchmark test which counts memory. The idea is to

1. Have a single thread running.
2. Create a new array to store your objects to allocate. So these objects won't be collected during GC run.
3. System.gc(), memoryBefore = runtime.totalMemory() - runtime.freeMemory()
4. Allocate your objects. Put them into the array.
5. System.gc(), memoryAfter = runtime.totalMemory() - runtime.freeMemory()

This is a technique I used in my lightweight micro-benchmark tool which is capable of measuring memory allocation with byte-precision.

I had this issue when I upgraded the versions of JUnit from 5.7.0 to 5.8.2. Try with version 5.7.0 for org.junit.jupiter:junit-jupiter-api and org.junit.jupiter:junit-jupiter-engine

You should start your unit-tests with Debug as > JUnit test