The combined power of JUnit, Guice and Mockito. Plus it sounds like a cool martial art.

Related tags

Spring Boot Jukito
Overview

Jukito

The combined power of JUnit, Guice and Mockito. Plus it sounds like a cool martial art.


So you started using dependency injection because somebody told you it would make your tests simpler? But as you gaze at your deep hierarchy of test classes, "simple" is not exactly the word you think of. Plus, creating a new mock whenever you add a parameter to an injected constructor gets old very quickly.

You are not alone! And Jukito was created specifically for people like you. Read on, or get started right away!

If you use Google Guice, or if your GWT application uses Gin, then Jukito is the perfect antidote to your unit testing headaches. Now you can write tests like this:

@RunWith(JukitoRunner.class)
public class EmailSystemTest {

  @Inject EmailSystemImpl emailSystem;
  Email dummyEmail;

  @Before
  public void setupMocks(
      IncomingEmails incomingEmails,
      EmailFactory factory) {
    dummyEmail = factory.createDummy();
    when(incomingEmails.count()).thenReturn(1);
    when(incomingEmails.get(0)).thenReturn(dummyEmail);
  }

  @Test
  public void shouldFetchEmailWhenStarting(
      EmailView emailView) {
    // WHEN
    emailSystem.start();

    // THEN
    verify(emailView).addEmail(dummyEmail);
  }
}

That's right, Jukito lets you @Inject fields exactly as if your test class was injected with Guice. You can also inject parameters into your @Test, @Before and @After methods. Guice's just-in-time binding automatically instantiate your concrete classes, like EmailFactory. What about interfaces like IncomingEmails or EmailView? Jukito mocks them out automatically for you using mockito!

Let's look at another example:

@RunWith(JukitoRunner.class)
public class CalculatorTest {

  public static class Module extends JukitoModule {
    protected void configureTest() {
      bindMany(Calculator.class,
          ScientificCalculator.class,
          BusinessCalculator.class);

      bindManyInstances(AdditionExample.class, 
          new AdditionExample(1, 1, 2),
          new AdditionExample(10, 10, 20),
          new AdditionExample(18, 24, 42));
    }
  }

  @Test
  public void testAdd(@All Calculator calculator, @All AdditionExample example) {
    // WHEN
    int result = calculator.add(example.a, example.b);

    // THEN
    assertEquals(example.expected, result);
  }
}

As you see here, Jukito lets you define your very own test module, where you can bind classes just like a regular Guice module. It doesn't stop there, however. The bindMany methods let you bind different classes or instances to the same interface. Combined with the powerful @All annotation this lets you easily run a single test on a whole suite of test examples. The code above will run a total of six tests!

Getting Started

Read the wiki to find out everything Jukito has to offer, and join the discussion!

Latest Release

  • 1.5

Links

Thanks to

Arcbees.com

Atlassian

IntelliJ

Comments
  • Many injectors

    Many injectors

    Test showing expected behavior of @All annotation in factory methods declared in Modules.

    Runner is expected to create a separated Injector and set of tests methods for every implementation bound to Key build of @All and some others types.

    opened by przemekgalazka 26
  • issue 40 and 41

    issue 40 and 41

    Christian, still code needs to be formated but maybe you can format it since updating checkstyle config to be more environment agnostic may take you some time

    EDIT (Christian) https://code.google.com/p/jukito/issues/detail?id=40 https://code.google.com/p/jukito/issues/detail?id=41

    opened by przemekgalazka 26
  • Using existing modules via new @UseModules annotation.

    Using existing modules via new @UseModules annotation.

    Example:

    @RunWith(JukitoRunner.class)
    @UseModules({ FooModule.class, BarModule.class}
    public class MyTest {
      // Tests methods  
    }
    

    The example is equivalent to the following inner static module class approach.

    @RunWith(JukitoRunner.class)
    public class MyTest {
      static class Module extends JukitoModule {
        @Override
          protected void configureTest() {
            install(new FooModule());
            install(new BarModule());
          }
        }
      // Test methods
    }
    
    opened by yln 13
  • allow inheritance of @UseModules

    allow inheritance of @UseModules

    This pull request allows the @UseModules annotation to be used on base classes.

    This would be very useful in the following scenario, which I come across often: You have 10 different repository classes, and one test class for each repository. You want all test classes to extend RepositoryTestBase because they all need some standard dependency setup, and you want to use the @UseModules annotation on RepositoryTestBase to install a few Guice modules.

    I updated JukitoRunner so that it checks for the @UseModules annotation on all super classes and merges the modules into a set. I also updated UseModulesTest to extend a base class to show that this works.

    opened by aldenquimby 11
  • Restructured pom to add samples project

    Restructured pom to add samples project

    @christiangoudreau Is that how you wanted to add a samples project?

    I also reformated the code so it's 4 spaces everywhere. If any styling changes are needed, I suggest I do them in this PR so the whole project will be uniform.

    What I see is that jukito use "one empty line at beginning of class"

    jukito-structure

    opened by meriouma 10
  • Jukito Cartesian product misfire?

    Jukito Cartesian product misfire?

    Here's my test class (a node can have a list of neighbours):

    @RunWith(JukitoRunner.class)
    public class NodeTest {
        public static class Module extends JukitoModule {
            protected void configureTest() {
                bindMany(Node.class, PlainNode.class);
            }
        }
    
        @Test
        public void testAddNeighbour(@All Node node, Node n2) {
            // Act
            node.addNeighbour(n2);
    
            // Assert
            assertTrue(node.getClass().getSimpleName(), node.getNeighbours().contains(n2));
        }
    }
    

    And I'm getting this failure:

    [junit] Testcase: testAddNeighbour took 0.001 sec
    [junit] Testcase: testAddNeighbour took 0.007 sec
    [junit]     FAILED
    [junit] Node$$EnhancerByMockitoWithCGLIB$$7aead885
    [junit] junit.framework.AssertionFailedError: Node$$EnhancerByMockitoWithCGLIB$$7aead885
    [junit]     at com.kaizen.mapdone.test.NodeTest.testAddNeighbour(NodeTest.java:42)
    [junit]     at org.jukito.InjectedStatement.evaluate(InjectedStatement.java:75)
    [junit]     at org.jukito.JukitoRunner.run(JukitoRunner.java:166)
    

    So it looks like Jukito is executing the test twice, once with "node" being a mock.

    Is this expected behaviour? I'd expect the test to be called once; with params of type (PlainNode, Mock) -- so either I'm confused, or Jukito's doing the wrong thing!

    Either resolution is fine by me :)

    opened by ahri 9
  • Named @All

    Named @All

    Based on the patch from issue 32.

    Extension to the @All annotation and the bindMultiple() methods which allows to group multiple instances/classes by a name and have only the ones with a given name injected into a test.

    i.e.:

    bindManyNamedInstances(Integer.class, "even", 2, 4, 6);
    bindManyNamedInstances(Integer.class, "odd", 1, 3, 5);
    
    @Test
    public void testCombination(@All("even") int e, @All("odd") int o) {
       ...
    }
    
    opened by sclassen 9
  • Enabling the use of UseModules on methods to override class level UseMod...

    Enabling the use of UseModules on methods to override class level UseMod...

    I often encounter situations where I need to override the UseModules declarations in a specific test method, however this was not possible. It looked very simple to implement this feature of adding UseModules to override the class level modules used just for a specific test method.

    Thanks again for a wonderful product. Jukito rocks!

    opened by ghost 7
  • Injecting inner classes doesn't give an informative error message.

    Injecting inner classes doesn't give an informative error message.

    Guice doesn't support injections into inner classes. It gives an informative error message about why. But, if you try to do the same thing with Jukito, you get little; Jukito will inject a mock of the instance that Guice was not able to create. Here's an example:

    import static org.junit.Assert.*;
    
    import org.junit.Before;
    import org.junit.Test;
    
    import com.google.inject.AbstractModule;
    import com.google.inject.Guice;
    import com.google.inject.Inject;
    import com.google.inject.Injector;
    
    public class InnerGuiceExample {
        public static class Module extends AbstractModule {
            @Override
            protected void configure() {
                bind(String.class).toInstance("hello world!");
            }
        }
    
        Foo f;
    
        @Before
        public void setUp() {
            Injector inj = Guice.createInjector(new Module());
            f = inj.getInstance(Foo.class);
        }
    
        @Test
        public void test() {
            assertEquals("hello world!", f.toString());
        }
    
        public class Foo {
            @Inject String test;
    
            public String toString() {
                return test;
            }
        }
    }
    

    And Guice's error message:

    com.google.inject.ConfigurationException: Guice configuration errors:
    
    1) Injecting into inner classes is not supported.  Please use a 'static' class (top-level or nested) instead of com.techemet.server.InnerGuiceExample$Foo.
      while locating com.techemet.server.InnerGuiceExample$Foo
    
    1 error
        at com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1004)
        at com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:961)
        at com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1013)
        at com.techemet.server.InnerGuiceExample.setUp(InnerGuiceExample.java:26)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        ...
    

    Here's the Jukito equivalent of the same code:

    import static org.junit.Assert.*;
    
    import org.jukito.JukitoModule;
    import org.jukito.JukitoRunner;
    import org.junit.Test;
    import org.junit.runner.RunWith;
    
    import com.google.inject.Inject;
    
    @RunWith(JukitoRunner.class)
    public class InnerJukitoExample {
        public static class Module extends JukitoModule {
            @Override
            protected void configureTest() {
                bind(String.class).toInstance("hello world!");
            }
        }
    
        @Inject Foo f;
    
        @Test
        public void test() {
            assertEquals("hello world!", f.toString());
        }
    
        public class Foo {
            @Inject String test;
    
            public String toString() {
                return test;
            }
        }
    }
    

    With error message:

    org.junit.ComparisonFailure: expected:<[hello world!]> but was:<[Mock for Foo, hashCode: 936146014]>
        at org.junit.Assert.assertEquals(Assert.java:115)
        at org.junit.Assert.assertEquals(Assert.java:144)
        at com.techemet.server.InnerJukitoExample.test(InnerJukitoExample.java:25)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    
    opened by durron597 7
  • Fixed issue #30

    Fixed issue #30

    Added an extra conditional to prevent using MockProvider if it's an inner class, and added a test to verify that the new version works correctly. This fixes issue #30

    opened by durron597 6
  • JukitoRunner should call MockitoAnnotations.initMocks(Object)

    JukitoRunner should call MockitoAnnotations.initMocks(Object)

    When using MockitoJunitRunner, it is not necessary to explicitly call MockitoAnnotations.initMocks(Object) to have @Mock annotated fields injected.

    That's very handy, and IMHO missing from JukitoRunner...

    (or am I missing something?)

    opened by jfrantzius 6
  • Jukito does not work well with ExpectedException rule

    Jukito does not work well with ExpectedException rule

    Using ExpectedException to test for expected exception does not work as intended, as Jukito's InjectedAfterStatements.evaluate() wraps and rethrows all exceptions as org.junit.internal.runners.model.MultipleFailureException.MultipleFailureException(List<Throwable>)

    This behavior would be ok for multiple exceptions, e.g. when also catching Guice-related exceptions in addition to exceptions which occurred in the actual test. But when there is only one exception, this should be re-thrown directly instead of wrapping it into MultipleFailureException.

    This can actually easily be done by using org.junit.runners.model.MultipleFailureException.assertEmpty(List<Throwable>) which first checks if there is only a single exception and if so rethrows it directly. Multiple exceptions are still wrapped into a MultipleFailureException as it used to be in Jukito.

    opened by metaschell 2
  • Gradle 5.1 breaks Jukito's @All when using JUnit 5 useJUnitPlatform

    Gradle 5.1 breaks Jukito's @All when using JUnit 5 useJUnitPlatform

    Here's a minimal failing project: https://github.com/slayful/minimal-jukito-gradle-5.1-failing-project I'm suspecting there's an issue when generating test cases or their names, maybe. Here's the stack trace with the issue.

    java.lang.AssertionError
    	at org.gradle.api.internal.tasks.testing.processors.TestOutputRedirector.setOutputOwner(TestOutputRedirector.java:49)
    	at org.gradle.api.internal.tasks.testing.processors.CaptureTestOutputTestResultProcessor.completed(CaptureTestOutputTestResultProcessor.java:80)
    	at org.gradle.api.internal.tasks.testing.results.AttachParentTestResultProcessor.completed(AttachParentTestResultProcessor.java:56)
    	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
    	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
    	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
    	at org.gradle.internal.actor.internal.DefaultActorFactory$BlockingActor.dispatch(DefaultActorFactory.java:122)
    	at org.gradle.internal.actor.internal.DefaultActorFactory$BlockingActor.dispatch(DefaultActorFactory.java:97)
    	at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
    	at com.sun.proxy.$Proxy3.completed(Unknown Source)
    	at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestExecutionListener.executionFinished(JUnitPlatformTestExecutionListener.java:110)
    	at org.junit.platform.launcher.core.TestExecutionListenerRegistry$CompositeTestExecutionListener.lambda$executionFinished$5(TestExecutionListenerRegistry.java:92)
    	at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
    	at org.junit.platform.launcher.core.TestExecutionListenerRegistry.notifyTestExecutionListeners(TestExecutionListenerRegistry.java:59)
    	at org.junit.platform.launcher.core.TestExecutionListenerRegistry.access$100(TestExecutionListenerRegistry.java:28)
    	at org.junit.platform.launcher.core.TestExecutionListenerRegistry$CompositeTestExecutionListener.executionFinished(TestExecutionListenerRegistry.java:92)
    	at org.junit.platform.launcher.core.ExecutionListenerAdapter.executionFinished(ExecutionListenerAdapter.java:56)
    	at org.junit.vintage.engine.execution.RunListenerAdapter.fireExecutionFinished(RunListenerAdapter.java:202)
    	at org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:160)
    	at org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:76)
    	at org.junit.runner.notification.SynchronizedRunListener.testFinished(SynchronizedRunListener.java:56)
    	at org.junit.runner.notification.RunNotifier$7.notifyListener(RunNotifier.java:190)
    	at org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:72)
    	at org.junit.runner.notification.RunNotifier.fireTestFinished(RunNotifier.java:187)
    	at org.junit.internal.runners.model.EachTestNotifier.fireTestFinished(EachTestNotifier.java:38)
    	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:331)
    	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
    	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
    	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
    	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
    	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
    	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
    	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
    	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
    	at org.jukito.JukitoRunner.run(JukitoRunner.java:227)
    	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
    	at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
    	at org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:39)
    	at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
    	at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
    	at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
    	at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
    	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
    	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
    	at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
    	at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
    	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
    	at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
    	at org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:79)
    	at org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:70)
    	at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:220)
    	at org.junit.platform.launcher.core.DefaultLauncher.lambda$execute$6(DefaultLauncher.java:188)
    	at org.junit.platform.launcher.core.DefaultLauncher.withInterceptedStreams(DefaultLauncher.java:202)
    	at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:181)
    	at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:128)
    	at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:102)
    	at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatformTestClassProcessor.java:82)
    	at org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor.stop(JUnitPlatformTestClassProcessor.java:78)
    	at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.stop(SuiteTestClassProcessor.java:61)
    	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
    	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
    	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
    	at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
    	at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
    	at com.sun.proxy.$Proxy2.stop(Unknown Source)
    	at org.gradle.api.internal.tasks.testing.worker.TestWorker.stop(TestWorker.java:132)
    	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
    	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
    	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
    	at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:175)
    	at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:157)
    	at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:404)
    	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
    	at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
    	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
    	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    	at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
    	at java.base/java.lang.Thread.run(Thread.java:834)
    
    opened by slayful 0
  • @UseModules on test method does not create mocks

    @UseModules on test method does not create mocks

    I am trying to create a test where I have a @UseModules on a test mode to setup a dependency different from other test methods. But as a consequence objects are not mocked as is the case with using the @UseModules on the test class.

    This unit test show It in action. The testWithoutUseModules gets a mocked HttpServletRequest, while the testWithUseModules gives a Guice error that no implementation was bound for the HttpServletRequest parameter. Maybe I am misreading or misunderstanding it.

    @RunWith(JukitoRunner.class)
    @UseModules(MockingTest.ModuleA.class)
    public class MockingTest {
      @Test
      public void testWithoutUseModules(HttpServletRequest request) {
        assertNotNull(request);
      }
    
      @Test
      @UseModules(ModuleB.class)
      public void testWithUseModules(HttpServletRequest request) {
        assertNotNull(request);
      }
      public static class ModuleA extends AbstractModule {
        @Override
        protected void configure() {
        }
      }
    
      public static class ModuleB extends AbstractModule {
        @Override
        protected void configure() {
        }
      }
    }
    
    opened by dnouls 1
  • Support JUnit 5

    Support JUnit 5

    JUnit 5 introduces a new extension mechanism. It would be nice if there was a JukitoExtension for JUnit 5. Is there any interest in officially supporting JUnit 5?

    opened by JeffreyFalgout 2
  • Jukito & archaius2-guice don't play nicely together

    Jukito & archaius2-guice don't play nicely together

    Hi,

    I've been investigating an issue with archaius2 & Jukito, where a configuration injected into a component that is initialised by Jukito is provided to the wrong test.

    The symptom is that if you use a Config in one test, then all subsequent tests won't have their Config updated:

    This test will pass:

    @RunWith(JukitoRunner.class)
    @UseModules(Module.class)
    public class HangingReferenceTest {
    
        public static class Module extends AbstractModule {
            @Override
            protected void configure() {
                install(new ArchaiusModule() {
    
                    @Override
                    protected void configureArchaius() {
                        Map<String, String> configurationValues = new HashMap<>();
    
                        configurationValues.put("value1", "one");
    
                        bindDefaultConfig().toInstance(MapConfig.from(configurationValues));
                    }
                });
            }
    
        }
        
        @Inject
        Provider<Config> configProvider;
    
        @Test
        public void testConfig() {
            assertThat(configProvider.get().getString("value1"), is("one"));
        }
    
    }
    

    But this test will fail, and if you look through the values of the Config, it just has "value1":

    @RunWith(JukitoRunner.class)
    @UseModules(Module.class)
    public class HangingReference2Test {
    
        public static class Module extends AbstractModule {
            @Override
            protected void configure() {
                install(new ArchaiusModule() {
    
                    @Override
                    protected void configureArchaius() {
                        Map<String, String> configurationValues = new HashMap<>();
    
                        configurationValues.put("value2", "two");
    
                        bindDefaultConfig().toInstance(MapConfig.from(configurationValues));
                    }
                });
            }
    
        }
    
        @Inject
        Provider<Config> configProvider;
    
        @Test
        public void testConfig() {
            assertThat(configProvider.get().getString("value2"), is("two"));
        }
    
    }
    

    I've been digging around in Jukito and have tracked it down to this bit of code in JukitoModule:

            // Make sure needed keys from Guice bindings are bound as mock or to instances
            // (but not as test singletons)
            for (Key<?> keyNeeded : keysNeeded) {
                addNeededKey(keysObserved, keysNeeded, keyNeeded, false);
                keysNeedingTransitiveDependencies.add(keyNeeded);
            }
    

    Is there a particular reason that you force bind in concrete instances that Jukito observes? Guice should provide them regardless and if I change the code to the follwing then everything is fine in archaius2 and also in your unit tests:

        // Make sure needed keys from Guice bindings are bound as mock or to instances
        // (but not as test singletons)
        for (Key<?> keyNeeded : keysNeeded) {
          TypeLiteral<?> typeToBind = keyNeeded.getTypeLiteral();
          Class<?> rawType = typeToBind.getRawType();
          if (!keysObserved.contains(keyNeeded) && canBeInjected(typeToBind)
              && !shouldForceMock(rawType) && !isAssistedInjection(keyNeeded)) {
            keysObserved.add(keyNeeded);
          }
          keysNeedingTransitiveDependencies.add(keyNeeded);
        }
    

    Thanks in advance.

    opened by petehannam 0
  • Support @Provides methods for specifying instances to @All injected tests

    Support @Provides methods for specifying instances to @All injected tests

    Instead of

    public static Module extends TestModule {
      protected void configureTest() {
        bindMany(SomeInterface.class, Impl1.class, Impl2.class);
      }
    }
    ...
    @Test
    someTest(@All SomeInterface interface) {
     ...
    }
    

    I would like to be able to do:

    public static Module extends TestModule {
      protected void configureTest() {
        install(new SharedModule());
      }
    
      @Provides
      @Instance
      SomeInterface  provideImpl1() {   
        return new Impl1();
      }
    
      @Provides
      @Instance
      SomeInterface provideImpl2(final SomeTypeFromSharedModule info) {
        return new Impl2(info.get());
      }
    }
    ...
    @Test
    someTest(@All SomeInterface interface) {
     ...
    }
    

    As you can see, the latter approach allows me to construct test instances using info from other injected types, whereas the current approach doesn't allow me access to other types that may have been installed.

    Also, it would be great to specify the test name for the junit runner, perhaps on the @Instance annotation.

    opened by mmadson 0
Releases(jukito-parent-1.5)
This project uses the artificial potential field method to realize the path planning of the robot, and completes the trajectory optimization through other settings. It can also be combined with laser SLAM, target recognition and other technologies for path planning.

FRCAutoDriver 项目说明 Project Instruction 本项目利用人工势场法,实现机器人的路径规划,并通过其他设置完成轨迹优化,还可以结合激光SLAM、目标识别等技术进行路径规划 This project uses the artificial potential field

ZhangzrJerry 2 Sep 9, 2022
ReDoSHunter: A Combined Static and Dynamic Approach for Regular Expression DoS Detection

ReDoSHunter ReDoSHunter is a combined static and dynamic approach for regular expression DoS detection. LATEST NOTE (updated at 2021.09.13): ReDoSHunt

Yeting Li 43 Dec 23, 2022
A manager tool to categorize game assets such as images and sounds/music. The tool enables you to tag these files, so that finding them by tags allows fast searches.

BtAssetManager This application allows you to easily categorize large amounts of image and sound files. You can apply tags to each individual file to

null 21 Sep 15, 2022
A simple live streaming mobile app with cool functionalities and time extension, and live chat. With a payment system integrated. Server is designed with socket.io to give you full flexibility.

Video Live Streaming Platform Android A simple live streaming mobile app with cool functionalities and time extension, and live chat. With a payment s

Dev-Geek 2 Dec 16, 2022
The Apache Software Foundation 605 Dec 30, 2022
A new rank core that will be cool SoonTM

Alchemist A new rank core that will be cool SoonTM Made by 98ping, utilized projects from devrawr and aikiar Updates We have new updates and features

Max 11 Jan 2, 2023
Photo live wallpaper with auto dark mode and power-efficient animations

Pallax Android: Photo Live Wallpaper Pallax Android is an Android app that lets you convert your current static home screen background into a stunning

Patrick Zedler 13 Dec 17, 2022
A web application to generate Java source code with spring-boot and mybatis-plus

A web application to generate Java source code with spring-boot and mybatis-plus. Also, The class of Domain,Mapper,XML of Mapper Interface,Service,Controller are included. You can change the data source what you want to generate for your project in app running without restart this code -generator application.

Weasley 3 Aug 29, 2022
Guns基于SpringBoot 2,致力于做更简洁的后台管理系统,完美整合springmvc + shiro + mybatis-plus + beetl!Guns项目代码简洁,注释丰富,上手容易,同时Guns包含许多基础模块(用户管理,角色管理,部门管理,字典管理等10个模块),可以直接作为一个后台管理系统的脚手架!

Guns基于Spring Boot2,致力于做更简洁的后台管理系统。包含系统管理,代码生成,多数据库适配,SSO单点登录,工作流,短信,邮件发送,OAuth2登录,任务调度,持续集成,docker部署等功。支持Spring Cloud Alibaba微服务。社区活跃,版本迭代快,加群免费技术支持。

冯硕楠 3.6k Jan 5, 2023
Spring-Boot-Plus is a easy-to-use, high-speed, high-efficient,feature-rich, open source spring boot scaffolding

Everyone can develop projects independently, quickly and efficiently! What is spring-boot-plus? A easy-to-use, high-speed, high-efficient, feature-ric

geekidea 2.3k Dec 31, 2022
参考 DDD/Clean Architecture 设计理念,整合 Spring Boot/Spring Security/Mybatis Plus/Vavr 的 Spring Realworld 应用案例

Demo · 更多项目 · 参考资料 ms-spring-ddd-examples Unified Domain-driven Layered Architecture for MicroService Apps,试图探索一套切实可行的应用架构规范,可以复制、可以理解、可以落地、可以控制复杂性的指导

王下邀月熊 19 Sep 23, 2022
以教学为目的的电商系统。包含ToB复杂业务、互联网高并发业务、缓存应用;DDD、微服务指导。模型驱动、数据驱动。了解大型服务进化路线,编码技巧、学习Linux,性能调优。Docker/k8s助力、监控、日志收集、中间件学习。前端技术、后端实践等。主要技术:SpringBoot+JPA+Mybatis-plus+Antd+Vue3。

简介 bcMall 是一个以教学为目的的电商系统。bcMall将为你展现一个典型的系统演进过程,所使用的主流技术完全开放。 它包含ToB复杂业务、互联网高并发业务、缓存应用;DDD、微服务指导。模型驱动、数据驱动。了解大型服务进化路线,编码技巧、学习Linux,性能调优。Docker/k8s助力、监

xjjdog 411 Jan 3, 2023
【多模块微服务脚手架平台——Ancba】前后端分离架构SpringBoot 2.x、SpringCloud、SpringAdmin、Spring Security、Mybatis-plus、(Shiro)、JWT、Feign、Nacos、Knif4j等。

Ancba 打造Blog.Core项目的SpringBoot微服务版,但是更强大 ?? Ancba (Another New CLI By Alacrity) 另一个全新的敏捷脚手架(单体/模块化/微服务都可支持)。 核心知识点与进度 ?? 在 ..../resources/application-

ansonzhang 35 Nov 29, 2022
基于RuoYi-Vue集成 Lombok+Mybatis-Plus+Undertow+knife4j+Hutool+Feign 重写所有原生业务 定期与RuoYi-Vue同步

平台简介 RuoYi-Vue-Plus 是基于 RuoYi-Vue 针对 分布式集群 场景升级 定期与 RuoYi-Vue 同步 集成 Lock4j dynamic-datasource 等分布式场景解决方案 集成 Mybatis-Plus Lombok Hutool 等便捷开发工具 适配重写相关业

CrazyLionLi 110 Jan 4, 2023
热部署插件deployment-plus,支持文件动态热编译

deployment-plus 热部署插件deployment-plus,支持文件动态热编译 ##使用方式: package com.deployment; import com.deployment.polling.filepolling.ClassLoaderActuator; /** *

ycsky 7 Apr 1, 2022
Spring Boot starter for JustAuth Plus.

Spring Boot starter for JustAuth Plus.

Fujie 5 Jun 23, 2022
SpringBoot SpringSecurity Jpa mybatis-plus websocket Redis camunda Vue3 Vite ant-design VbenAdmin vxe-table bpmn.js

SpringBoot SpringSecurity Jpa mybatis-plus websocket Redis camunda Vue3 Vite ant-design VbenAdmin vxe-table bpmn.js

zsvg 16 Dec 13, 2022