JUnit część II

kontynuacja rozpoczęła się tutaj -> JUnit część I Chcę też pokazać jak działa ta metoda Assert.fail(String)- jeśli ta metoda zostanie wywołana, test zakończy się niepowodzeniem. Wygodne, jeśli inne metody tej klasy Assert nie mogą nas sprawdzić. Powiedzmy, że musimy zabronić akceptowania plików new String(“”). Spróbujmy to zrobić za pomocą konstruktora i wyłączmy przekazywanie name = “” || null, age = 0; Sex = null. No to chodźmy... Dodałem dodatkowe pola do testów

private User user;
private User user1;
private User user2;

private User userNotAdd;
private User userNotAdd1;

i zmieniłem metodęsetUp()

@Before
public void setUp() throws Exception {
    user = new User(„Eugeniusz”, 35, Sex.MALE);
    user1 = new User("Przystań", 34, Sex.FEMALE);
    user2 = new User("Alina", 7, Sex.FEMALE);

    userNotAdd = new User("", 0, null);
    userNotAdd1 = new User(null, 0, null);
}

i dodał trzy metody testowe

@Test
public void newUser_EMPTY_NAME() {
    for (User user : User.getAllUsers()){
        if (user.getName() != null && user.getName().isEmpty()) {
            Assert.fail("Попытка создания пользователя с пустым именем");
        }
    }
}

@Test
public void newUser_AGE_ZERO() {
    for (User user : User.getAllUsers()) {
        if (user.getAge() <= 0) {
            Assert.fail("Попытка создания пользователя c не допустимым возрастом");
        }
    }
}

@Test
public void newUser_SEX_NO_NULL() {
    for (User user : User.getAllUsers()) {
        if (user.getSex() == null) {
            Assert.fail("Попытка создания пользователя с указанием пола = null");
        }
    }
}

W testach przeglądamy listę dodanych użytkowników i sprawdzamy, czy nie ma jakichś nieprawidłowych danych. Uruchamiamy testy zbiorczo i widzimy następujący obrazek... Widać, że nasze testy dla konstruktora są zepsute, a także przechwytywanych jest jeszcze kilka testów.Teraz musimy zmienić konstruktor tak, aby się nie dodawał użytkownika z nieprawidłowymi parametrami do listy użytkowników, zróbmy to tak:

public User(String name, int age, Sex sex) {
    if (name != null && !name.isEmpty() && age > 0 && sex != null){
        this.name = name;
        this.age = age;
        this.sex = sex;

        if (!hasUser()) {
            countId++;
            this.id = countId;
            allUsers.put(id, this);
        }
    }
}

Przeprowadzamy testy i widzimy, że wszystko jest pięknie.Podsumowując , JUnit to doskonałe narzędzie do pokrywania kodu testami. JUnit będzie działał jeszcze lepiej w połączeniu z Mavenem , budując projekt Maven na pewno przeprowadzi wszystkie testy, a potem zbuduje nasz gotowy projekt, ale jeśli testy się nie powiodą, projekt nie zostanie zbudowany i poznamy przyczyny, i łatwiej będzie ustalić, gdzie dokładnie doszło do awarii. Drugą zaletą JUnit jest przypadek Refactoringu , testy JUnit pomogą nam upewnić się, że logika naszego programu nie zostanie zepsuta. A w dużych projektach życie bez automatycznego systemu testowania nie jest możliwe, chociaż może i jest to możliwe, ale Twój projekt będzie działać z prędkością ślimaka… czy jakoś tak… Jeśli dobrze pokryjemy nasz kod testami , wtedy możemy być pewni, że nasz klient, nasz produkt będzie się świetnie sprawdzał. P/S Wyrażam głęboką wdzięczność Wiktorowi Siergiejewowi!!! Oto linki do lekcji wideo, w której nas uczył:

• testowanie Javy
• Testowanie Java (ciąg dalszy)

Dziękuję za uwagę!!! Miej dobry nastrój!!! I niech Bóg uratuje Cię od hinduskiego kodeksu!!! ...również, jeśli ktoś jest zainteresowany zagłębieniem się w kod źródłowy artykułu... niech puka... podzielę się początkiem tutaj - JUnit część I