How to use decamelizeMatcherName method of org.mockito.internal.util.StringUtil class

Testing the interaction with the OSGi container is, strictly speaking, an integration test. For this you could use Pax Exam, it's a bit fiddly to get the hang of, but works really well (especially if you're using maven and/or karaf features).

Additionally you can use TinyBundles which can dynamically create deployable bundles/fragments from within your test (very cool) to mock out other bundles/fragments to ensure inter-bundle integration without bring up a full environment.

For unit or small scale integration testing (i.e. without the container) then you can just mock out the BundleContext (or if using DS the ComponentContext as well) should you need it.

I'm a little unclear about your questions in the bullet points. If there's an internal POJO then it'd be your responsibility to wire up dependencies via setters, otherwise if it exposed to the OSGi service registry then dependencies are resolved by the framework (either DS or ServiceTracker).

Also subclassing something to overwrite a creator-method means you're no longer testing the original class - this is a code smell - try refactoring it to pass in the creator code as a separate class (constructor or setter), then this new creator code (socket creation) can be tested independently (with no consideration for OSGi or even the protocol class where it will be used).

Yes, you can. The trick here is that you have to get to the instance of the lambda that is passed to the registerMessage and then execute that expression and then you can verify the result.

For the purpose of a meaningful example I created this Handler class that contains the dispatchMessage that you want to test:

public class Handler {

    private Dispatcher dispatcher = new Dispatcher();

    public void dispatchMessage(MessageHandler handler, String argument1, String argument2, Long argument3) {

        handler.registerMessage(() -> {
            dispatcher.dispatch(argument1,
                    argument2,
                    argument3);
        });

    }

    interface MessageHandler {
        void registerMessage(Runnable run);
    }

    static class Dispatcher {
        void dispatch(String a, String b, long c){
            // Do dispatch
        }
    }
}

What you have to remember is that a lambda expression is just a short hand form to pass a function to a method. In this example the function is the run method of a Runnable. Therefore the method registerMessage of the interface for MessageHandler takes a Runnable as it's argument. I also included an implementation for the Dispatcher, which is called from within registerMessage. The test for this looks like this:

@RunWith(MockitoJUnitRunner.class)
public class HandlerTest {
    @Mock
    private Dispatcher dispatcher;
    @InjectMocks
    private Handler classUnderTest;
    @Captor
    private ArgumentCaptor<Runnable> registerMessageLambdaCaptor;

    @Test
    public void shouldCallDispatchMethod() {
        final String a = "foo";
        final String b = "bar";
        final long c = 42L;

        MessageHandler handler = mock(MessageHandler.class);

        classUnderTest.dispatchMessage(handler, a, b, c);

        verify(handler).registerMessage(registerMessageLambdaCaptor.capture());

        Runnable lambda = registerMessageLambdaCaptor.getValue();

        lambda.run();

        verify(dispatcher).dispatch(a, b, c);
    }
}

There is an ArgumentCaptor for the lambda expression which we use in the first verification of the registerMessage. After that verification we can retrieve the lambda expression from the captor. The type of the lambda expression is Runnable, as defined in the MessageHandler interface. Hence we can call the run method on it and then verify that the dispatch method on the Dispatcher was called with all the appropriate arguments.

I think there is some contradiction in what you say:

1. Created a Library...that was designed as a Spring Boot Application.
2. Library can be used across multiple applications that require its utilities.

If you implement "1" then there is a module with spring boot maven/gradle plugin configured to create a JAR of the application which is a library.

But if you have, say, module X that wishes to use your library, its impossible to add the dependency on your library in this module, spring boot JAR artifacts are not JARs in a Java Sense... So this won't work in both IDE and maven (I mean technically you'll have compilation errors).

Then you write something that completely makes sense: You say that the library by itself doesn't have a main class/@SpringBootApplication annotated class. From this I conclude that its not a spring boot application, but rather a spring boot starter module.

In this case you should not use @SpringBootTest annotation since it mimics the way of starting up the spring boot application (finds main class, scans the packages according to the package structure, loads the configurations and so forth). You don't need all this. Well, maybe technically you can still create a main class annotated with @SpringBootApplication and put it into src/test/java/.../ in a relevant package, but it doesn't really makes sense.

So basically you have two choices:

1. You can test the utilities without spring at all as if the utility is just a Java class, mock the dependency with Mockito and you're good to go. Since these tests are fast, it you be the best option.

2. You can run the integartion test by means of loading the spring context with all the required beans created by the application.

@ExtendWith(SpringExtension.class)
@ContextConfiguration(classes = {MyLibraryConfiguration.class})
public class SampleLibraryTest {

    @Autowired 
    private SomeBeanFromTheLibrary theBean;

    @Test
    public void testFoo() {
      ....
    }
}

Now although you can use component scanning (in this case you'll need slightly different annotations), in the example I've assumed that you're using java config, register all the beans of the library there and create a spring.factories that uses this Java Configuration file to create an autoconfiguration (you add a dependency on the library in module X and it loads the beans defined in the library automatically).

This @ExtendsWith (@RunWith for junit 4) has nothing to do with Spring Boot, it behaves as a "plain" spring, you can autowire beans, create mock beans, there is caching of configurations, etc.

You can change the System.in stream using System.setIn() method.

Try this,

@Test
public void shouldTakeUserInput() {
    InputOutput inputOutput= new InputOutput();

    String input = "add 5";
    InputStream in = new ByteArrayInputStream(input.getBytes());
    System.setIn(in);

    assertEquals("add 5", inputOutput.getInput());
}

You have just modified the System.in field. System.in is basically an InputStream which reads from the console (hence your input in the console). But you just modified it and let the system to read from the provided inputstream instead. So it wont read from console anymore but from the inputstream provided.

Mockito 1.10.5 has introduced this feature.

For the code sample in the question, here is one way to capture the varargs:

    ArgumentCaptor<String> varArgs = ArgumentCaptor.forClass(String.class);
    A mock = Mockito.mock(A.class);
    mock.setNames("Jeff", "Mike", "John");
    Mockito.verify(mock).setNames(varArgs.capture());

    //Results may be validated thus:
    List<String> expected = Arrays.asList("Jeff", "Mike", "John");
    assertEquals(expected, varArgs.getAllValues());

Please see the ArgumentCaptor javadoc for details.

PowerMockito.doAnswer(new Answer<Void>() {
    /* ... */
}).when(Connector.newConnection(Mockito.any(ConnectorConfig.class)));

Your when is the problem. In normal Mockito, using any doAnswer/doReturn/etc call, you have to place the call you're stubbing outside of the call to when, like so:

Mockito.doAnswer(new Answer<Void>() {
    /* ... */
}).when(yourMock).callVoidMethod();
//            ^^^^^^

PowerMockito further requires that calls to static methods happen in the next statement, like so:

PowerMockito.doAnswer(new Answer<Void>() {
    /* ... */
}).when(Connector.class); Connector.newConnection(/*...*/);
//                    ^^^^^^

Note that from 2009 (~1.3.x) to 2013 (~1.5.x), the docs were actually inconsistent, alluding to a zero-arg when despite all signatures requiring at least a class literal.

Obligatory PSA: It's generally a good idea to avoid mocking types you don't own, though opinions may vary on that one.

The cause of your problem is that Spock makes methods it spies on synchronized. Particularly, the method MockController.handle(), through which all such calls go, is synchronized. You'll easily notice it if you add a pause and some output to your getStrings() method.

public List<String> getStrings() throws InterruptedException {
    System.out.println(Thread.currentThread().getId() + " goes to sleep");
    Thread.sleep(1000);
    System.out.println(Thread.currentThread().getId() + " awoke");
    if (strings == null) {
        strings = loadStrings();
    }
    return strings;
}

This way Spock inadvertently fixes your concurrency problem. Mockito obviously uses another approach.

A couple of other thoughts on your tests:

First, you don't do much to ensure that all your threads have come to the getStrings() call at the same moment, thus decreasing the probability of collisions. Long time may pass between threads start (long enough for the first one to complete the call before others start it). A better approach would be to use some synchronization primitive to remove the influence of threads startup time. For instance, a CountDownLatch may be of use here:

given:
def final CountDownLatch latch = new CountDownLatch(10)
def loader = Spy(ExampleLoader)
def threads = (0..<10).collect { new Thread({
    latch.countDown()
    latch.await()
    loader.getStrings()
})}

Of course, within Spock it will make no difference, it's just an example on how to do it in general.

Second, the problem with concurrency tests is that they never guarantee that your program is thread safe. The best you can hope for is that such test will show you that your program is broken. But even if the test passes, it doesn't prove thread safety. To increase chances of finding concurrency bugs you may want to run the test many times and gather statistics. Sometimes, such tests only fail once in several thousands or even once in several hundreds thousands of runs. Your class is simple enough to make guesses about its thread safety, but such approach will not work with more complicated cases.

I've needed this several times as well. I've put together a small sample below, which you'd want to adjust to your needs. Basically, you create your own Appender and add it to the logger you want. If you'd want to collect everything, the root logger is a good place to start, but you can use a more specific if you'd like. Don't forget to remove the Appender when you're done, otherwise you might create a memory leak. Below I've done it within the test, but setUp or @Before and tearDown or @After might be better places, depending on your needs.

Also, the implementation below collects everything in a List in memory. If you're logging a lot you might consider adding a filter to drop boring entries, or to write the log to a temporary file on disk (Hint: LoggingEvent is Serializable, so you should be able to just serialize the event objects, if your log message is.)

import org.apache.log4j.AppenderSkeleton;
import org.apache.log4j.Level;
import org.apache.log4j.Logger;
import org.apache.log4j.spi.LoggingEvent;
import org.junit.Test;

import java.util.ArrayList;
import java.util.List;

import static org.hamcrest.CoreMatchers.is;
import static org.junit.Assert.assertThat;

public class MyTest {
    @Test
    public void test() {
        final TestAppender appender = new TestAppender();
        final Logger logger = Logger.getRootLogger();
        logger.addAppender(appender);
        try {
            Logger.getLogger(MyTest.class).info("Test");
        }
        finally {
            logger.removeAppender(appender);
        }

        final List<LoggingEvent> log = appender.getLog();
        final LoggingEvent firstLogEntry = log.get(0);
        assertThat(firstLogEntry.getLevel(), is(Level.INFO));
        assertThat((String) firstLogEntry.getMessage(), is("Test"));
        assertThat(firstLogEntry.getLoggerName(), is("MyTest"));
    }
}

class TestAppender extends AppenderSkeleton {
    private final List<LoggingEvent> log = new ArrayList<LoggingEvent>();

    @Override
    public boolean requiresLayout() {
        return false;
    }

    @Override
    protected void append(final LoggingEvent loggingEvent) {
        log.add(loggingEvent);
    }

    @Override
    public void close() {
    }

    public List<LoggingEvent> getLog() {
        return new ArrayList<LoggingEvent>(log);
    }
}

You must use PowerMockito.spy() instead of Mockito.spy()!

Try to import static org.powermock.api.mockito.PowerMockito.spy;