[JAVA] Lassen Sie uns zusammenfassen, warum eine Konstruktorinjektion empfohlen wird

Konstruktorinjektion und Feldinjektion

• Vor kurzem? Ich habe das Gefühl, ein solides Verständnis dafür zu haben, warum die Injektion von Konstruktoren empfohlen wird. Deshalb habe ich beschlossen, diesen Artikel zu schreiben, weil ich meine Gedanken und mein Verständnis zusammenfassen wollte.
• Es wird davon ausgegangen, dass der folgende Code mit SpringBoot, Java, JPA implementiert wird.

Vor- und Nachteile der Feldinjektion

• ** Verdienst **
• Bei der Feldinjektion ist die Injektion einfach, da Sie einfach "@ Autowired" über dem Feld hinzufügen.
• Wenn Sie mehr Dinge zu injizieren haben, fügen Sie einfach ein Feld hinzu und fügen Sie "@ Autowired" hinzu.
• ** Fehler **
• Der Test wird schmerzhaft. (Siehe unten)

Implementierungsbeispiel mit Feldinjektion

@Service
public class BookService{
    
    @Autowired
    private BookDao bookDao;
    
    @Autowired
    private HogeDao hogeDao;

    /**
     *Gibt ein Buch zurück, das dem Argument bookId entspricht
     */
    public Book selectById(int bookId){
        Optional<Book> wrappedBook = bookDao.findById(bookId);
        return wrappedBook.orElseThrow(() -> NotFoundException("Nein"));
    }
                          .
                          .
                          .
}

Vor- und Nachteile der Konstruktorinjektion

• ** Verdienst **
• Obwohl es einen Nachteil gibt, dass der Umfang der Beschreibung zunimmt, kann das Feld unveränderlich gemacht werden.
• Einfach zu testen. (Siehe unten)
• ** Fehler **
• Bei der Konstruktorinjektion ist der Umfang der Beschreibung größer als bei der Feldinjektion.
• Wenn mehr Dinge injiziert werden müssen, ist es im Vergleich zur Feldinjektion etwas schwieriger, Änderungen vorzunehmen.

Implementierungsbeispiel mit Konstruktorinjektion

@Service
public class BookService{
    private final BookDao bookDao;
    private final HogeDao hogeDao;
    
    @Autowired // → Spring4.Diese Anmerkung kann weggelassen werden, wenn sie 3 oder mehr beträgt
    public BookService(BookDao bookDao, HogeDao hogeDao){
        this.bookDao = bookdao;
        this.hogeDao = hogedao;
    }

    /**
     *Gibt ein Buch zurück, das dem Argument bookId entspricht
     */
    public Book selectById(int bookId){
        Optional<Book> wrappedBook = bookDao.findById(bookId);
        return wrappedBook.orElseThrow(() -> NotFoundException("Nein"));
    }
                          .
                          .
                          .
}

Verbesserte Testbarkeit durch Konstruktorinjektion

• Wie oben erwähnt, ist das Testen mit der Konstruktorinjektion einfacher.

Beim Testen einer Klasse, die mit Feldinjektion implementiert wurde

• Mit "@ Autowired" injizierte Felder können mit "@ MockBean" von Spring Boot verspottet werden.
• Da die von SpringBoot bereitgestellte Anmerkung verwendet wird, sind "@RunWith (SpringRunner.class)" und "@ SpringBootTest" erforderlich.

@RunWith(SpringRunner.class)
@SpringBootTest
public class BookServiceTests{

    @Autowired    
    private BookService bookService;

    @MockBean
    private BookDao bookDao;

    @MockBean
    private HogeDao hogeDao;

 
    @Test
public void Bücher mit der angegebenen bookId abrufen können(){
        // setUp
        var expected = new Book(1, "Buchname"); 
        when(bookDao.findById(1)).thenReturn(expected);
        var bookService = new BookService();

        // execute
        var actual = bookService.selectById(1);

        // verify
        assertThat(...Unten weggelassen
    }
}

• Auf den ersten Blick sieht es sehr einfach aus, da Sie nur "@ MockBean" hinzufügen müssen, aber der Spring Boot Test nimmt viel Zeit für einen Komponententest in Anspruch ...
• Ich erhalte häufig die Fehlermeldung "Anwendungskontext konnte nicht erstellt werden". (Erfahren)
• Tritt auf, wenn die in application.yml (.properties) beschriebenen DB-Informationen falsch sind.
• Wenn die Datenbank nicht ausgeführt wird, wird der Test überhaupt nicht ausgeführt
• Nicht weil die Datenbank nicht ausgeführt wird, sondern weil die Implementierung so ist, dass wenn es in @ Table keine Tabelle gibt, diese automatisch generiert wird ...?
• In einem Test, der nicht mit DB zusammenhängt, erscheint der Fehler "DB ist ..." und die Belastung ist groß (groß)

Beim Testen einer durch Konstruktorinjektion implementierten Klasse

• Es kann ein bisschen mühsam sein, sich mit der @ Before-Methode zu verspotten.
• @RunWith (SpringRunner.class) und @ SpringBootTest waren für die durch Feldinjektion implementierten Tests erforderlich, müssen hier jedoch nicht hinzugefügt werden.

public class BookServiceTests{ 
    private BookService bookService;
    private BookDao bookDao;
    private HogeDao hogeDao;

    @Before
    public void setUp(){
        bookDao = Mockito.mock(BookDao.class);
        hogeDao = Mockito.mock(HogeDao.class);
        bookService = new BookService(bookDao, hogeDao);
    }
 
    @Test
public void Bücher mit der angegebenen bookId abrufen können(){
        // setUp
        var expected = new Book(1, "Buchname"); 
        when(bookDao.findById(1)).thenReturn(expected);
        var bookService = new BookService();

        // execute
        var actual = bookService.selectById(1);

        // verify
        assertThat(...Unten weggelassen
    }
}

• Da keine Anmerkungen zu Spring Boot hinzugefügt werden, ist der Test reibungslos.

• Sie können ohne Stress testen, ohne an Fehlern wie "Anwendungskontext konnte nicht erstellt werden" oder "DB ist ..." zu leiden: smile:

• Wenn es schwierig ist, sich mit der Methode "@ Before" selbst zu verspotten, können Sie sich leicht verspotten, indem Sie "@ Mock" von Mockito hinzufügen.

@RunWith(MockitoJUnitRunner.class)
public class BookServiceTests{ 
    private BookService bookService;

    @Mock
    private BookDao bookDao;
    @Mock
    private HogeDao hogeDao;

    @Before
    public void setUp(){
        bookService = new BookService(bookDao, hogeDao);
    }
    //Unten weggelassen

• Bitte beachten Sie, dass "@RunWith (MockitoJUnitRunner.class)" erforderlich ist.

Referenz

• https://humble-mumble.com/mockbean-vs-mock/#st-toc-h-1