[JAVA] [Spring Boot] Ich dachte über testbaren Code von DI nach

Einführung

Wie können Sie das Spring Framework (Boot) implementieren, ohne die einzufügende Klasse zu ändern, während Sie versuchen, sie zu "testbarem Code" zu machen, was der Vorteil von DI ist? Ich habe darüber nachgedacht, und ich habe selbst darüber nachgedacht, also möchte ich über seinen Inhalt schreiben.

Annahme

Was ist Frühling? Was ist DI? Ich werde nicht darüber reden. Die Erklärung von hier ist wunderbar. Bitte beziehen Sie sich darauf. Ich habe auch an der eingangs erwähnten Lernsitzung teilgenommen, aber es war eine gute Studie.

Was ich mich gefragt habe

Selbst wenn Sie den Code testbar machen, selbst wenn Sie eine Stub-Klasse zum Testen erstellen, weil die zu injizierende Klasse nicht implementiert ist, müssen Sie mindestens den injizierten Teil neu schreiben, wenn diese Klasse abgeschlossen ist. Ich dachte.

Zum Beispiel so.

@RestController
public class DemoController {

	@Autowired
	DemoServiceStub demoService;
	//DemoService demoService;	//Schalten Sie den Kommentar hier zum Testen aus

	@GetMapping("/echo")
	public String echo() {
		return demoService.getMessage();
	}
}

public class DemoService {
	String getMessage(){
		//Wird noch implementiert
		return "xxx";
	}
}

public class DemoServiceStub {
	String getMessage(){
		return "foo is stub";
	}
}

Wie ich im Kommentar geschrieben habe, muss ich den Injektionsteil zwischen der regulären Klasse und der Stub-Klasse umschalten. Wenn ich nur eine bestimmte Methode testen möchte, denke ich nicht, dass sie mich betrifft, aber ich fühle mich immer noch unwohl, wenn ich mit dem Feld spiele.

Also, hier ist, worüber ich nachgedacht und behoben habe.

@RestController
public class DemoController {

	@Autowired
	@Qualifier("demoservice")  //Geben Sie den Namen des Injektionsziels an. Wechseln Sie nicht zwischen Normal und Stub.
	DemoService demoService;

	@GetMapping("/echo")
	public String echo() {
		return demoService.getMessage();
	}
}

//Machen Sie eine Schnittstelle
public interface DemoService {
	String getMessage();
}


@Service(value = "demoserviceWIP")  //Gib ihm einen Namen. Tragen Sie es nicht mit einem Stummel.
public class DemoServiceImpl implements DemoService {
	public String getMessage() {
		//Wird noch implementiert
		return "xxx";
	};
}

@Service(value = "demoservice")  //Gib ihm einen Namen
public class DemoServiceImplStub implements DemoService {
	String getMessage(){
		return "foo is stub";
	}
}

Dadurch entfällt die Notwendigkeit, die zu testende Quelle (in diesem Fall DemoController) sowohl für legitime als auch für Stubs zu optimieren. Ich bin der Meinung, dass diese Methode auch dann effektiv ist, wenn mehrere Klassen in der Schnittstelle implementiert werden sollen. Wenn es im Frühjahr mehrere Typen (Klassen) gibt, die Beans registrieren, kann nicht bestimmt werden, welche registriert werden sollen. Daher scheint der Name auf diese Weise aufgelöst zu werden. (Es fühlt sich eher so an, als hätte ich von diesem Mechanismus einen Hinweis für diesen Fall erhalten.)

Rezension

• Implementierung über eine Schnittstelle, um reguläre Klassen und Stub-Klassen gemeinsam zu machen ――Ich bin der Meinung, dass dies als DI in erster Linie das Minimum sein sollte.
• Geben Sie der injizierten Klasse einen Alias (Wertattribut "@ Service"). --Lösen Sie den Namen auf der Einspritzseite (@ Qualifier)
• Die Einspritzseite nimmt unabhängig vom Implementierungsstatus der Einspritzseite keine Änderungen vor. --Schalten Sie den Injektionsnamen auf der zu injizierenden Seite

Schließlich

Es ist eine Methode, die kaum herauskam, selbst wenn ich gegoogelt habe. Es kann zu offensichtlich oder anti-gemustert sein. In diesem Fall weisen Sie bitte darauf hin.