Разширено тестване с Mockito

1.1 Библиотека Mockito

Днес ще се запознаем с разширеното тестване. По-конкретно, с библиотеката Mockito . Дори не си и помисляйте да излезете от този бизнес.

Първо, тази библиотека е стандарт в пролетното тестване . Което всъщност е стандартът в индустрията за Java бекенд разработка.

Второ, ще трябва да напишете тестове за вашия Spring code . Единственият начин да разберете, че бекендът, който сте написали, работи Howто трябва, е да извикате методи на неговия API . И да го направиш с тестове е 10 пъти по-лесно, отколкото без тях. Ще се убедите сами.

Можете да добавите библиотеката Mockito към вашата, pom.xmlкато използвате codeа:

<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-junit-jupiter</artifactId>
    <version>4.2.0</version>
    <scope>test</scope>
</dependency>

Целият изходен code за проекта Mockito може да бъде намерен на GitHub .

1.2 Фалшиви обекти

И така, Howво е това Mockito и защо е толкова добро?

В процеса на разработване и разработване на тестване много често имаше нужда да се вмъкне няHowъв вид „мъниче“ в codeа instead of реален обект.

Например, codeът, който работи с базата данни, се тества и променя нещо там. Добре е преди всеки тест състоянието на тази база да е едно и също (в противен случай тестовете ще са различни). И бих искал базата да е по-проста, за да се върнат бързо тези състояния.

Или, например, тествате code, който изпраща полезен SMS. А за директна поща той използва няHowъв платен SMS Gateway. Би било хубаво да поставите няHowъв виртуален шлюз в него, за да тествате codeа, за да не изпращате стотици SMS-и на неразбираеми хора.

Или вашият code изисква данни от други уеб сървъри, които просто не са налични на тестовия сървър. Или пишете code за онлайн разплащания, който трябва да бъде тестван 50 пъти и едва след това да бъде разрешен за използване в реални финансови канали.

Мисля, че разбирате ... Виртуалните обекти, or Howто ги наричат ​​още обекти, са много полезно нещо.

И тук идва трудността - Java има статично писане. Това означава, че за да ReadDatabaseприсвоите препратка към обект към променлива instead of обект от тип VirtualDatabase, трябва да наследите класа VirtualDatabaseот RealDatabase.

Тогава се оказва, че класът има RealDatabaseкуп частни методи и променливи, които съхраняват препратки към други реални обекти, и не можете да напишете нормален мъниче по този начин. На теория е добре, но на практика е задънена улица.

И тук идва на помощ ( можете да прочететеDynamicProxy по-подробно ), който се появи още в Java 5. Той ви позволява да създавате виртуални обекти, към които компилаторът няма оплаквания.

Такива виртуални обекти се наричат ​​mocks (от думата mock - оформление). Библиотеката Mockito успя да издигне работата с тези макети до безпрецедентна висота. Оттам, между другото, и името на библиотеката.

1.3 Анотация @ExtendWith

Библиотеката Mockito работи чудесно с JUnit, дори може да се счита за нейно разширение.

Има два начина да активирате библиотеката Mockito във вашите модулни тестове. Първият начин е да добавите специална анотация:

@ExtendWith(MockitoExtension.class)
public class MockitoAnnotationTest {
    ...
}

Вторият начин е да активирате работата му чрез извикване на метода openMocks():

public class MockitoAnnotationTest {
    @BeforeEach
    public void init() {
        MockitoAnnotations.openMocks(this);
   }
}

Най-често ще видите първата опция, но понякога е полезно да знаете, че има и втора.