Mit junit test können Sie das Befehlszeilenargument an die Spring Boot-Anwendung übergeben

Ich habe einen Weg gefunden, Junit-Tests zu erstellen, die gut mit SpringBoot zusammenarbeiteten, indem der ApplicationContext in meinen Test eingefügt und ein CommandLineRunner mit den erforderlichen Parametern aufgerufen wurde.

Der endgültige Code sieht so aus:

package my.package.

import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.CommandLineRunner;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.context.ApplicationContext;
import org.springframework.test.context.junit4.SpringRunner;

@RunWith(SpringRunner.class)
@SpringBootTest
class AsgardBpmClientApplicationIT {

    @Autowired
    ApplicationContext ctx;

    @Test
    public void testRun() {
        CommandLineRunner runner = ctx.getBean(CommandLineRunner.class);
        runner.run ( "-k", "arg1", "-i", "arg2");
    }

}

Ich befürchte, dass Ihre Lösung nicht auf eine Weise funktioniert, die Sie vorgestellt haben (bis Sie Ihr eigenes Testframework für Spring implementiert haben).

Wenn Sie Tests ausführen, führt Spring (genauer gesagt der Test SpringBootContextLoader) Ihre Anwendung auf ihre eigene Weise aus. Es instantiiert SpringApplication und ruft die run-Methode ohne Argumente auf. Es verwendet auch niemals Ihre in der Anwendung implementierte main-Methode.

Sie können Ihre Anwendung jedoch so umgestalten, dass Sie sie testen können. 

Ich denke (da Sie Spring verwenden) könnte die einfachste Lösung mithilfe von Federkonfigurationseigenschaften anstelle von reinen Befehlszeilenargumenten implementiert werden. (Sie sollten sich jedoch bewusst sein, dass diese Lösung eher für "Konfigurationsargumente" verwendet werden sollte, da dies der Hauptzweck des configuration properties-Mechanismus von Springs ist.)

Parameter mit der @Value-Annotation lesen:

@SpringBootApplication
public class Application implements CommandLineRunner {

    @Value("${myCustomArgs.customArg1}")
    private String customArg1;

    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }

    @Override
    public void run(String... args) throws Exception {

        Assert.notNull(customArg1);
        //...
    }
}

Beispieltest:

@RunWith(SpringRunner.class)
@SpringBootTest({"myCustomArgs.customArg1=testValue"})
public class CityApplicationTests {

    @Test
    public void contextLoads() {
    }
}

Und wenn Sie Ihre Befehlszeilen-App ausführen, fügen Sie einfach Ihre benutzerdefinierten Parameter hinzu:

--myCustomArgs.customArg1=testValue

Ich würde SpringBoot aus der Gleichung herausnehmen.

Sie müssen lediglich die run-Methode testen, ohne Spring Boot zu durchlaufen, da es nicht Ihr Ziel ist, Spring Boot zu testen, nicht wahr? wirft immer eine IllegalArgumentException, wenn keine Argumente bereitgestellt werden? Der gute alte Gerätetest funktioniert immer noch, um eine einzelne Methode zu testen:

@RunWith(MockitoJUnitRunner.class)
public class ApplicationTest {

    @InjectMocks
    private Application app = new Application();

    @Mock
    private Reader reader;

    @Mock
    private Writer writer;

    @Test(expected = IllegalArgumentException.class)
    public void testNoArgs() throws Exception {
        app.run();
    }

    @Test
    public void testWithArgs() throws Exception {
        List list = new ArrayList();
        list.add("test");
        Mockito.when(reader.get(Mockito.anyString())).thenReturn(list);

        app.run("myarg");

        Mockito.verify(reader, VerificationModeFactory.times(1)).get(Mockito.anyString());
        Mockito.verify(writer, VerificationModeFactory.times(1)).write(list);
    }
}

Ich habe Mockito verwendet, um Mocks für Reader und Writer zu injizieren:

<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-all</artifactId>
    <version>1.9.0</version>
    <scope>test</scope>
</dependency>

In Ihrem Code autowire Springs ApplicationArguments. Verwenden Sie getSourceArgs(), um die Befehlszeilenargumente abzurufen.

public CityApplicationService(ApplicationArguments args, Writer writer){        
    public void writeFirstArg(){
        writer.write(args.getSourceArgs()[0]);
    }
}

In Ihrem Test simulieren Sie die ApplicationArguments.

@RunWith(SpringRunner.class)
@SpringBootTest
public class CityApplicationTests {
@MockBean
private ApplicationArguments args;

    @Test
    public void contextLoads() {
        // given
        Mockito.when(args.getSourceArgs()).thenReturn(new String[]{"Berlin"});

        // when
        ctx.getBean(CityApplicationService.class).writeFirstArg();

        // then
        Mockito.verify(writer).write(Matchers.eq("Berlin"));

    }
}

Wie Maciej Marczuk vorgeschlagen, bevorzuge ich auch die Verwendung von Springs Environment-Eigenschaften anstelle von Befehlszeilenargumenten. Wenn Sie die Federn-Syntax --argument=value nicht verwenden können, können Sie eine eigene PropertySource schreiben, diese mit Ihrer Befehlszeilenargumentensyntax füllen und der ConfigurableEnvironment hinzufügen. Dann müssen alle Ihre Klassen nur Federeigenschaften verwenden.

Z.B.

public class ArgsPropertySource extends PropertySource<Map<String, String>> {

    ArgsPropertySource(List<CmdArg> cmdArgs, List<String> arguments) {
        super("My special commandline arguments", new HashMap<>());

        // CmdArgs maps the property name to the argument value.
        cmdArgs.forEach(cmd -> cmd.mapArgument(source, arguments));
    }

    @Override
    public Object getProperty(String name) {
        return source.get(name);
    }
}


public class SetupArgs {

    SetupArgs(ConfigurableEnvironment env, ArgsMapping mapping) {           
        // In real world, this code would be in an own method.
        ArgsPropertySource = new ArgsPropertySource(mapping.get(), args.getSourceArgs());
        environment
            .getPropertySources()
            .addFirst(propertySource);
    }
}

BTW: 

Da ich nicht genug Reputationspunkte habe, um eine Antwort zu kommentieren, möchte ich hier noch eine hart erlernte Lektion hinterlassen:

Die CommandlineRunner ist keine so gute Alternative. Seit der run()-Methode wird alwyas direkt nach der Erstellung des Federkontextes ausgeführt. Sogar in einer Testklasse. So wird es laufen, bevor der Test gestartet ist ... 

Wie in dieser Antwort erwähnt, bietet Spring Boot derzeit keine Möglichkeit, die DefaultApplicationArguments , die es verwendet, abzufangen/zu ersetzen. Ein natürlicher Boot-Weg, den ich zur Lösung dieses Problems verwendete, bestand darin, meine Läuferlogik zu verbessern und einige autarke Eigenschaften zu verwenden.

Zuerst habe ich eine Eigenschaftskomponente erstellt:

@ConfigurationProperties("app") @Component @Data
public class AppProperties {
    boolean failOnEmptyFileList = true;
    boolean exitWhenFinished = true;
}

... die Eigenschaftskomponente automatisch an meinen Läufer angeschlossen:

@Service
public class Loader implements ApplicationRunner {

    private AppProperties properties;

    @Autowired
    public Loader(AppProperties properties) {
        this.properties = properties;
    }
    ...

... und in der Variable run bestätige ich nur, wenn diese Eigenschaft aktiviert ist, die standardmäßig für die normale Anwendung true verwendet wird:

@Override
public void run(ApplicationArguments args) throws Exception {
    if (properties.isFailOnEmptyFileList()) {
        Assert.notEmpty(args.getNonOptionArgs(), "Pass at least one filename on the command line");
    }

    // ...do some loading of files and such

    if (properties.isExitWhenFinished()) {
        System.exit(0);
    }
}

Damit kann ich diese Eigenschaften so anpassen, dass sie in einem Unit-Test-freundlichen Modus ausgeführt werden:

@RunWith(SpringRunner.class)
@SpringBootTest(properties = {
        "app.failOnEmptyFileList=false",
        "app.exitWhenFinished=false"
})
public class InconsistentJsonApplicationTests {

    @Test
    public void contextLoads() {
    }

}

Ich brauchte den exitWhenFinished-Teil, da mein spezieller Läufer normalerweise System.exit(0) aufruft und auf diese Weise den Unit-Test in einem halb ausgefallenen Zustand verlässt.