JUnit i Mocks in Liferay

Question

Potrzebuję wykonać testy JUnit przy użyciu Mockito lub PowerMock lub czegoś jeszcze, ale nie wiem od czego zacząć. Stworzyłem folder testowy, ustawiłem mockito, ale co mam zrobić dalej? Nie mogłem znaleźć żadnych przykładów, więc utknąłem z tym. Czy możesz mi pokazać, jak napisać ten test JUnit lub przynajmniej dać jakiś pomysł.

public void deleteAuthor(ActionRequest actionRequest, ActionResponse actionResponse) 
     throws SystemException, PortalException { 
    long authorId = ParamUtil.getLong(actionRequest, "authorId"); 
    AuthorLocalServiceUtil.deleteAuthor(authorId); 
    SessionMessages.add(actionRequest, "deleted-author"); 
    log.info(DELETE_SUCCESS); 

} 

Albo to:

public void addAuthor(ActionRequest actionRequest, ActionResponse actionResponse) 
     throws IOException, PortletException, SystemException { 

    String authorName=ParamUtil.getString(actionRequest,"authorName"); 
    Author author=AuthorLocalServiceUtil.createAuthor(CounterLocalServiceUtil.increment()); 
    author.setAuthorName(authorName); 
    author=AuthorLocalServiceUtil.addAuthor(author);   
} 

PS: Jestem bardzo początkujący i zrobiłem tylko 1 test JUnit w moim życiu, więc jestem naprawdę zainteresowany dobrą radą. Z góry dziękuję!

---

UPD:

próbuję zrobić, aby czymś tak:

private BookAndAuthor portlet; 

@Before 
public void setUp() { 
    portlet = new BookAndAuthor(); 
} 


@Test 
public void testDeleteBookOk() throws Exception { 
    PowerMockito.mockStatic(BookLocalServiceUtil.class); 
    long id = 1; 
    Book book = BookLocalServiceUtil.createBook(id); 

    ActionRequest actionRequest = mock(ActionRequest.class); 
    ActionResponse actionResponse = mock(ActionResponse.class); 

    when(BookLocalServiceUtil.deleteBook(book)).thenReturn(null); 
    Book result = BookLocalServiceUtil.deleteBook(book); 
    assertEquals(result, null); 
} 

... ale bez powodzenia.

Answer 1

Prowadzimy JUnit testu przy użyciu następujących regulacji:

i. Utwórz folder test obok docroot w swoim portlecie.

ii. Dodaj folder unit, aby przetestować i utworzyć w nim swój package.

iii. Tworzenie portal-ext.properties plik w folderze test o następującej konfiguracji:

jdbc.default.driverClassName=com.mysql.jdbc.Driver 
jdbc.default.url=jdbc:mysql://localhost:3309/db_name?useUnicode=true&characterEncoding=UTF-8&useFastDateParsing=false 
jdbc.default.username=your_username 
jdbc.default.password=your_password 

jdbc.default.automaticTestTable=C3P0TestTable 
jdbc.default.idleConnectionTestPeriod=36000 
jdbc.default.maxIdleTime=1200 

IV. Utwórz klasę Apartament (słownie AbcSuite.java) w następujący sposób:.

package x.x.x; 

import org.junit.AfterClass; 
import org.junit.BeforeClass; 
import org.junit.runner.RunWith; 
import org.junit.runners.Suite; 

import com.liferay.portal.util.InitUtil; 

@RunWith(Suite.class) 
@Suite.SuiteClasses({ 
    // Where AxTest.class would be your test class name 
    A1Test.class, A2Test.class, AxTest.class 
}) 

public class AbcSuite { 

    @BeforeClass 
    public static void setUp() throws Exception { 
     // Loading properties and establishing connection with database 
     InitUtil.initWithSpring(); 
     System.out.println("X Portlet's Test Suite Execution : Started."); 
    } 

    @AfterClass 
    public static void tearDown() { 
     System.out.println("X Portlet's Test Suite Execution : Completed."); 
    } 
} 

v Utwórz klasę testową (słownie A1Test.java) w następujący sposób:

package x.x.x; 

import java.util.ArrayList; 

import org.junit.Assert; 
import org.junit.BeforeClass; 
import org.junit.Test; 

public class A1Test { 

    @BeforeClass 
    public static void setUp() throws Exception { 
     System.out.println("Test Running : A1Test"); 
    } 

    @Test 
    public void testAddAuthor() { 
     Author author = AuthorLocalServiceUtil.createAuthor(
      CounterLocalServiceUtil.increment()); 
     author.setAuthorName("Testcase Author"); 
     author = AuthorLocalServiceUtil.addAuthor(author); 

     Assert.assertNotNull(author); 
     Assert.assertTrue(author.getAuthorId() > 0); 
    } 
} 

że to! Można wykonać wszystkie przypadki testowe ze sobą za pomocą następującego polecenia:

ant test -Dtest.class=AbcSuite* 

lub oddzielnie jako:

ant test -Dtest.class=A1Test* 

Answer 2

będzie to odpowiedź niepopularna, ale ...

I odkryli, że testy JUnit z wieloma kpiącymi obiektami nie są szczególnie przydatne. Saldo pojawia się, gdy przyjrzymy się wielkości metody testu: setUp(): Im jest on dłuższy, tym mniejsza jest wartość testu. W świecie portletowym musiałbyś używać wielu masek, a będziesz bardziej zajęty tworzeniem kopii lustrzanych środowiska wykonawczego (i korygowaniem założeń, które o nim myślałeś) niż naprawiasz problemy, które znalazłeś tylko podczas tworzenia tego rodzaj testów.

Powiedział, że jest tu moja recepta

1. Zbuduj portletów z jedną myślą: Portlets to technologia UI. Interfejs użytkownika jest z natury trudny do przetestowania automatycznie. Utknąłeś między standardem JSR-286 a warstwą biznesową - dwie warstwy, które prawdopodobnie nie nadają się szczególnie dobrze do połączenia ich w testach.

2. Zachowaj swój kod warstwy UI tak absurdalnie prosty, że możesz przejść z tylko trochę przeglądu kodu. Dowiesz się z niego więcej niż z ogromnych procedur setUp() testów JUnit.

3. Wykreśl znaczący kod warstwy UI. Wyodrębnij go do własnej klasy lub metody narzędzia. Przetestuj to - zauważ, że prawdopodobnie nie potrzebujesz nawet pełnego obiektu PortletRequest, używaj tylko rzeczywistych danych, które są potrzebne, aby uzyskać wszystkie niezbędne testy integracji. Będą wykorzystywać pełny stos, a aplikacja zostanie wdrożona w środowisku testowym. Dostarczą dymnego testu, aby zobaczyć, czy twój kod faktycznie działa. Ale upewnij się, że testowanie prawidłowego okablowania nie spowalnia Cię: kod złożoności object.setStreet(request.getParameter("street")); nie powinien być testowany, a raczej sprawdzany pod kodem - i powinien być albo oczywiście prawidłowy, albo oczywiście nieprawidłowy.

4. Użyj odpowiednich standardów kodowania, aby ułatwić sobie recenzowanie. Na przykład. nazwać Pole tekstowe „ulicy”, czy to dane, które posiada, a nie „input42”

Z nich pamiętać: Kiedy piszesz portlet z kodem, który Twoim zdaniem powinny być testowane: Wyodrębnienie go. Wyeliminuj konieczność wyśmiewania obiektów portletowych lub warstwy biznesowej. Przetestuj wyodrębniony kod. Drugi { code block } w metodzie portletu może być wystarczająco jasny, aby usprawiedliwić ekstrakcję do oddzielnej klasy/metody, która może być zwykle testowana w sposób trywialny - i testy te będą całkowicie niezależne od Liferay, nauczą cię dużo o kodzie, jeśli zawiodą, oraz są znacznie łatwiejsze do zrozumienia niż te, które tworzą wiele fałszywych obiektów.

Wolę błądzić po stronie trywialności testów, niż po stronie zbyt skomplikowanych testów: zbyt skomplikowane testy spowolnią, zamiast dostarczyć sensownego wglądu. Zwykle kończą się niepowodzeniem, ponieważ założenie dotyczące środowiska wykonawczego było fałszywe i wymaga korekty.