Problem z tworzeniem obiektów w testach

LukaszCh233 napisał(a):

Może tak np. jeśli category A zawiera quiz B to aktualizacja category a sprawi, że quiz B uzyska zaktualizowaną category A. Dobry test czy nie?

Jeśli faktycznie potrzebujesz takiego zachowania w Twojej aplikacji to tak. Jeśli nie, to nie.

LukaszCh233 napisał(a):

Bez sensu sie to wydaje ale no nie wiem co mam testować a co nie. Usuwanie wyszukiwanie kategorii update.

Testuje się to co aplikacja ma robić - dodawanie quizów, usuwanie, granie w quizy, liczenie punktów, to co użytkownik ma zrobić z aplikacją. Triggerem do napisania testu powinno być dodanie zachowania.

We wcześniejszych postach posługiwałeś się określeniami "testy metody" albo "test klasy", i to jest ogólnie słabe podejście. Nie powinno być takiego 1:1, że każda klasa ma osobny test suite, i każda metoda ma osobny test.

Riddle napisał(a):

LukaszCh233 napisał(a):

Może tak np. jeśli category A zawiera quiz B to aktualizacja category a sprawi, że quiz B uzyska zaktualizowaną category A. Dobry test czy nie?

Jeśli faktycznie potrzebujesz takiego zachowania w Twojej aplikacji to tak. Jeśli nie, to nie.

nie no zaraz mnie coś strzeli xD nie wiem co ja potrzebuje chce napisać dobre testy, nigdzie nie znajde czegoś takiego jak ty mi mówisz, wszędzie są testy takie co pisałem na początku.

LukaszCh233 napisał(a):

Bez sensu sie to wydaje ale no nie wiem co mam testować a co nie. Usuwanie wyszukiwanie kategorii update.

Testuje się to co aplikacja ma robić - dodawanie quizów, usuwanie, granie w quizy, liczenie punktów, to co użytkownik ma zrobić z aplikacją. Triggerem do napisania testu powinno być dodanie zachowania.

No dodawanie quizów czyli mam po prostu przetestować dodawanie a jest to robione przez metode createQuizCategory no inaczej tego nie zrobie przecież nie rozumiem już nic.

We wcześniejszych postach posługiwałeś się określeniami "testy metody" albo "test klasy", i to jest ogólnie słabe podejście. Nie powinno być takiego 1:1, że każda klasa ma osobny test suite, i każda metoda ma osobny test.

No ale każda metoda prezentuje dane zachowanie czyli no musze ją tak jakby przetestować. Uzytkownik chce wybrać quiz jaki chce zrobić no to te zachowanie reprezentuje metoda findQuizById.

LukaszCh233 napisał(a):

nie no zaraz mnie coś strzeli xD nie wiem co ja potrzebuje chce napisać dobre testy, nigdzie nie znajde czegoś takiego jak ty mi mówisz

Ty tworzysz aplikację, Ty decydujesz jakie funkcjonalności ma mieć aplikacja, a więc Ty decydujesz jakie testy napisać.

LukaszCh233 napisał(a):

Testuje się to co aplikacja ma robić - dodawanie quizów, usuwanie, granie w quizy, liczenie punktów, to co użytkownik ma zrobić z aplikacją. Triggerem do napisania testu powinno być dodanie zachowania.

No dodawanie quizów czyli mam po prostu przetestować dodawanie a jest to robione przez metode createQuizCategory no inaczej tego nie zrobie przecież nie rozumiem już nic.

Okej, już tłumaczę. Chcesz przetestować "dodawanie quizów", spoko. Widzę że Twój pierwszy krok jest pójście od razu do metody która to robi, i przetestowanie jej. To jest zły krok.

Twoim krokiem powinno być, jeśli chcę przetestować "dodawanie quizów", to "co się powinno stać kiedy dodam quiz?". To jest ważne pytanie na które musisz sobie odpowiedzieć. Bez odpowiedzi na to pytanie nie ma sensu pisać dalszych testów.

LukaszCh233 napisał(a):

We wcześniejszych postach posługiwałeś się określeniami "testy metody" albo "test klasy", i to jest ogólnie słabe podejście. Nie powinno być takiego 1:1, że każda klasa ma osobny test suite, i każda metoda ma osobny test.

No ale każda metoda prezentuje dane zachowanie czyli no musze ją tak jakby przetestować. Uzytkownik chce wybrać quiz jaki chce zrobić no to te zachowanie reprezentuje metoda findQuizById.

"No ale każda metoda prezentuje dane zachowanie" no nie. Nie koniecznie. Czasem 20 różnych metod implementuje jedno zachowanie, a czasem 20 różnych zachowań jest załatwione przez jedną metodę. To że "każda metoda prezentuje dane zachowanie" to jest tylko w bardzo ograniczonych przypadkach.

Riddle napisał(a):

LukaszCh233 napisał(a):

nie no zaraz mnie coś strzeli xD nie wiem co ja potrzebuje chce napisać dobre testy, nigdzie nie znajde czegoś takiego jak ty mi mówisz

Ty tworzysz aplikację, Ty decydujesz jakie funkcjonalności ma mieć aplikacja, a więc Ty decydujesz jakie testy napisać.

LukaszCh233 napisał(a):

Testuje się to co aplikacja ma robić - dodawanie quizów, usuwanie, granie w quizy, liczenie punktów, to co użytkownik ma zrobić z aplikacją. Triggerem do napisania testu powinno być dodanie zachowania.

No dodawanie quizów czyli mam po prostu przetestować dodawanie a jest to robione przez metode createQuizCategory no inaczej tego nie zrobie przecież nie rozumiem już nic.

Okej, już tłumaczę. Chcesz przetestować "dodawanie quizów", spoko. Widzę że Twój pierwszy krok jest pójście od razu do metody która to robi, i przetestowanie jej. To jest zły krok.

Twoim krokiem powinno być, jeśli chcę przetestować "dodawanie quizów", to "co się powinno stać kiedy dodam quiz?". To jest ważne pytanie na które musisz sobie odpowiedzieć. Bez odpowiedzi na to pytanie nie ma sensu pisać dalszych testów.

No jak jak dodam quiz to moge go wyświetlić lub dodać do niego pytanie.

LukaszCh233 napisał(a):

We wcześniejszych postach posługiwałeś się określeniami "testy metody" albo "test klasy", i to jest ogólnie słabe podejście. Nie powinno być takiego 1:1, że każda klasa ma osobny test suite, i każda metoda ma osobny test.

No ale każda metoda prezentuje dane zachowanie czyli no musze ją tak jakby przetestować. Uzytkownik chce wybrać quiz jaki chce zrobić no to te zachowanie reprezentuje metoda findQuizById.

"No ale każda metoda prezentuje dane zachowanie" no nie. Nie koniecznie. Czasem 20 różnych metod implementuje jedno zachowanie, a czasem 20 różnych zachowań jest załatwione przez jedną metodę. To że "każda metoda prezentuje dane zachowanie" to jest tylko w bardzo ograniczonych przypadkach.

no dobra ale w moim przypadku zachowanie np. admin chce usunąć wszystkie quizCategory jest to jednza z opcji dla admina no i ją tylko repreznetuje włąśnie ta jedna metoda czyli deleteAllQuizCategories

LukaszCh233 napisał(a):

No jak jak dodam quiz to moge go wyświetlić lub dodać do niego pytanie.

Noi w końcu konkret jakiś. To chcąc napisać test pod "dodawanie quizu", powinieneś napisać test który wygląda tak:

Taki test mógłby wyglądać tak:

addQuiz("fruit");
addQuestionToQuiz("fruit", "do you like apples?");
assertQuizHasQuestions("fruit", 1);

Funkcja pomocnicza addQuiz() powinien pod spodem wołać Twoją funkcję do dodawania quizu.

LukaszCh233 napisał(a):

no dobra ale w moim przypadku zachowanie np. admin chce usunąć wszystkie quizCategory jest to jednza z opcji dla admina no i ją tylko repreznetuje włąśnie ta jedna metoda czyli deleteAllQuizCategories

Jeśli chcesz pisać dobre testy, to musisz przestać myśleć o funkcjonalnościach w kontekście "funkcjonalność jest reprezentowana przez metodę".

Jeśli chcesz napisać test pod to że administrator może usunąć kategorię, to powinno to wyglądać jakoś tak:

void adminCanDeleteCategory() {
  var category = quizCategory("fruits");
  var user = adminUser();
  deleteCategoryAs(user, category);
  assertCategoryDoesNotExist("fruits");
}

void userCanNotDeleteCategory() {
  var category = quizCategory("fruits");
  var user = regularUser();
  deleteCategoryAs(user, category); // co się powinno stać kiedy zwykły użytkownik spróbuje usunąć kategorię?
}

Riddle napisał(a):

LukaszCh233 napisał(a):

No jak jak dodam quiz to moge go wyświetlić lub dodać do niego pytanie.

Noi w końcu konkret jakiś. To chcąc napisać test pod "dodawanie quizu", powinieneś napisać test który wygląda tak:

Taki test mógłby wyglądać tak:

Kopiuj

addQuiz("fruit");
addQuestionToQuiz("fruit", "do you like apples?");
assertQuizHasQuestions("fruit", 1);

Funkcja pomocnicza addQuiz() powinien pod spodem wołać Twoją funkcję do dodawania quizu.

LukaszCh233 napisał(a):

no dobra ale w moim przypadku zachowanie np. admin chce usunąć wszystkie quizCategory jest to jednza z opcji dla admina no i ją tylko repreznetuje włąśnie ta jedna metoda czyli deleteAllQuizCategories

Jeśli chcesz pisać dobre testy, to musisz przestać myśleć o funkcjonalnościach w kontekście "funkcjonalność jest reprezentowana przez metodę".

Jeśli chcesz napisać test pod to że administrator może usunąć kategorię, to powinno to wyglądać jakoś tak:

Kopiuj

void adminCanDeleteCategory() {
  var category = quizCategory("fruits");
  var user = adminUser();
  deleteCategoryAs(user, category);
  assertCategoryDoesNotExist("fruits");
}

void userCanNotDeleteCategory() {
  var category = quizCategory("fruits");
  var user = regularUser();
  deleteCategoryAs(user, category); // co się powinno stać kiedy zwykły użytkownik spróbuje usunąć kategorię?
}

Skomplikowane to wszystko, czyli nazwa testu to whenCreateQuizSuccessThenCanAddQuestion_test? Nie ma co patrzeć na te metody tylko wymyślić kilka testów w których te metody będą wykorzystywane.
Ten drugi test z delete to taki sam jak mój tylko prostu napisany w inny sposób mam wrażenie.
Okey może coś z tej wiedzy uda się ulepić jakieś testy, będę próbować.

LukaszCh233 napisał(a):

Skomplikowane to wszystko, czyli nazwa testu to whenCreateQuizSuccessThenCanAddQuestion_test?

Ja bym go nazwał addQuestionToQuiz.

LukaszCh233 napisał(a):

Nie ma co patrzeć na te metody tylko wymyślić kilka testów w których te metody będą wykorzystywane.

Krok w dobrą stronę, ale jeszcze nie do końca.

Nie ma co patrzeć na te metody tylko, zastanowić się co aplikacja ma robić.

LukaszCh233 napisał(a):

Ten drugi test z delete to taki sam jak mój tylko prostu napisany w inny sposób mam wrażenie.

Prawdopodobnie aktualnie wykonywany kod jest podobny, ale właśnie ten "inny sposób napisania testu" ma największą wartość - bo nie zepsuje się jak zrobisz refaktor.

Riddle napisał(a):

LukaszCh233 napisał(a):

Skomplikowane to wszystko, czyli nazwa testu to whenCreateQuizSuccessThenCanAddQuestion_test?

Ja bym go nazwał addQuestionToQuiz.

No to w takim razie nie dotyczy on tworzenia quizu tylko pytania, mam taką metodę jak addQuestionsToQuiz.

LukaszCh233 napisał(a):

Nie ma co patrzeć na te metody tylko wymyślić kilka testów w których te metody będą wykorzystywane.

Krok w dobrą stronę, ale jeszcze nie do końca.

Nie ma co patrzeć na te metody tylko, zastanowić się co aplikacja ma robić.

LukaszCh233 napisał(a):

Ten drugi test z delete to taki sam jak mój tylko prostu napisany w inny sposób mam wrażenie.

Prawdopodobnie aktualnie wykonywany kod jest podobny, ale właśnie ten "inny sposób napisania testu" ma największą wartość - bo nie zepsuje się jak zrobisz refaktor.

Chyba też nikt nie bedzie wymagał ode mnie idealnych testów w projekcie do CV

LukaszCh233 napisał(a):

No to w takim razie nie dotyczy on tworzenia quizu tylko pytania, mam taką metodę jak addQuestionsToQuiz.

Może tak być. Więc są trzy wyjścia:

• albo dodawanie quizu jest obojętne, i testowanie tej "funkcji" w ogóle nie ma sensu
• albo sprawdzenie czy quiz się dodał da się zrobić tylko dodając pytanie - w takim wypadku ten test trzeba usunąć, skoro coś innego go już sprawdza
• albo może da się jakoś inaczej sprawdzić czy quiz jest dodany?
  • Jeśli tak, to należałoby napisać test pod to inne sprawdzenie - np. czy ilość quizów się zwiększa, lub coś takiego.

LukaszCh233 napisał(a):

Chyba też nikt nie bedzie wymagał ode mnie idealnych testów w projekcie do CV

Pytanie czy robisz projekt dla siebie, żeby się nauczyć, czy pod CV.

Jak pod CV to możesz zrobisz wszystkie najgorsze praktyki świata napisane na kolanie, i też będzie dobrze.

Riddle napisał(a):

LukaszCh233 napisał(a):

No to w takim razie nie dotyczy on tworzenia quizu tylko pytania, mam taką metodę jak addQuestionsToQuiz.

Może tak być. Więc są trzy wyjścia:

• albo dodawanie quizu jest obojętne, i testowanie tej "funkcji" w ogóle nie ma sensu
• albo sprawdzenie czy quiz się dodał da się zrobić tylko dodając pytanie - w takim wypadku ten test trzeba usunąć, skoro coś innego go już sprawdza
• albo może da się jakoś inaczej sprawdzić czy quiz jest dodany?
  • Jeśli tak, to należałoby napisać test pod to inne sprawdzenie - np. czy ilość quizów się zwiększa, lub coś takiego.

Ooo czyli jeszcze większe komplikacje

LukaszCh233 napisał(a):

Chyba też nikt nie bedzie wymagał ode mnie idealnych testów w projekcie do CV

Pytanie czy robisz projekt dla siebie, żeby się nauczyć, czy pod CV.

Jedno i drugie bo coś do tego CV musze wsadzić.

Jak pod CV to możesz zrobisz wszystkie najgorsze praktyki świata napisane na kolanie, i też będzie dobrze.

Nie no ja chcę żeby to wyglądało najlepiej jak umiem dlatego ciągle coś poprawiam i próbuję te testy. Chce żeby to sie nadało do CV a nie zapchaj dziura

LukaszCh233 napisał(a):

Ooo czyli jeszcze większe komplikacje

To jest tak na prawdę bardzo proste.

• Masz mylne przekonanie że testy się pisze pod funkcje i pod klasy. To jest błąd
• Dobre testy pisze się pod zachowanie:
  • dodaj quiz
  • dodaj pytanie
  • odpowiedz na quiz
  • dodaj kategorie
  • dodaj quiz do kategorii
  • usuń quiz z kategorii

I każdy ten test się pisze w stylu: "co ma się stać, kiedy zrobię Y"? I tyle.

LukaszCh233 napisał(a):

Nie no ja chcę żeby to wyglądało najlepiej jak umiem dlatego ciągle coś poprawiam i próbuję te testy. Chce żeby to sie nadało do CV a nie zapchaj dziura

No to zdecyduj się. Raz piszesz Chyba też nikt nie bedzie wymagał ode mnie idealnych testów w projekcie do CV a raz chcę żeby to wyglądało najlepiej jak umiem .

Riddle napisał(a):

LukaszCh233 napisał(a):

Ooo czyli jeszcze większe komplikacje

To jest tak na prawdę bardzo proste.

• Masz mylne przekonanie że testy się pisze pod funkcje i pod klasy. To jest błąd
• Dobre testy pisze się pod zachowanie:
  • dodaj quiz
  • dodaj pytanie
  • odpowiedz na quiz
  • dodaj kategorie
  • dodaj quiz do kategorii
  • usuń quiz z kategorii

I każdy ten test się pisze w stylu: "co ma się stać, kiedy zrobię Y"? I tyle.

wtedy to te funkcjonalnosci sie łączą tak jak z tym tworzeniem quizu i dodawaniem pytań.
rozumiem mniejwiecej o co Ci chodzi ale gorzej z napisaniem tego w formie testu.

LukaszCh233 napisał(a):

Nie no ja chcę żeby to wyglądało najlepiej jak umiem dlatego ciągle coś poprawiam i próbuję te testy. Chce żeby to sie nadało do CV a nie zapchaj dziura

No to zdecyduj się. Raz piszesz Chyba też nikt nie bedzie wymagał ode mnie idealnych testów w projekcie do CV a raz chcę żeby to wyglądało najlepiej jak umiem .

Dopiero się uczę więc nigdy nie zrobie idealnie i nie powinni tego wymagać ale to nie znaczy, że nie chce się nauczyć.
Też chce w końcu skończyć te CV i spróbować swoich sił coś rozesłać i może się uda a jak nie to cierpliwość i z czasem bedzie lepiej.
Testy repository był znacznie łatwiejsze.

LukaszCh233 napisał(a):

wtedy to te funkcjonalnosci sie łączą tak jak z tym tworzeniem quizu i dodawaniem pytań.
rozumiem mniejwiecej o co Ci chodzi ale gorzej z napisaniem tego w formie testu.

Muszą się łączyć, dlatego że Twoja domena jest połączona. Pytania są połączone z quizami, a quizy są połączone z kategoriami. To się tak mądrze nazywa "kohezja".

LukaszCh233 napisał(a):

Też chce w końcu skończyć te CV i spróbować swoich sił coś rozesłać i może się uda a jak nie to cierpliwość i z czasem bedzie lepiej.

Ja bym na Twoim miejscu rozesłal to CV już teraz.

LukaszCh233 napisał(a):

Testy repository był znacznie łatwiejsze.

Łatwo się pisze testy które nic nie testują

Riddle napisał(a):

LukaszCh233 napisał(a):

wtedy to te funkcjonalnosci sie łączą tak jak z tym tworzeniem quizu i dodawaniem pytań.
rozumiem mniejwiecej o co Ci chodzi ale gorzej z napisaniem tego w formie testu.

Muszą się łączyć, dlatego że Twoja domena jest połączona. Pytania są połączone z quizami, a quizy są połączone z kategoriami. To się tak mądrze nazywa "kohezja".

Ty to jesteś lepszy niż internet tyle wiedzy. Jutro będę nad tym siedział a jeszcze później są testy controllerów :)

LukaszCh233 napisał(a):

Też chce w końcu skończyć te CV i spróbować swoich sił coś rozesłać i może się uda a jak nie to cierpliwość i z czasem bedzie lepiej.

Ja bym na Twoim miejscu rozesłal to CV już teraz.

Dlaczego? Nie mam skończonego projektu żadnego, ciągle coś się znajduje do poprawy na lepsze.

LukaszCh233 napisał(a):

Testy repository był znacznie łatwiejsze.

Łatwo się pisze testy które nic nie testują

Ej no mówiłeś, że dobre są

LukaszCh233 napisał(a):

Ja bym na Twoim miejscu rozesłal to CV już teraz.

Dlaczego? Nie mam skończonego projektu żadnego, ciągle coś się znajduje do poprawy na lepsze.

Nic nie tracisz, a możesz zyskać.

LukaszCh233 napisał(a):

Łatwo się pisze testy które nic nie testują

Ej no mówiłeś, że dobre są

To miała być rada. Jeśli czujesz że pisanie testów sprawia że musisz nad nimi pomyśleć - to dobry znak. Jeśli piszesz testy "od strzała", to prawdopodobnie przyklepują implementacje i są niepomocne.

Riddle napisał(a):

LukaszCh233 napisał(a):

Ja bym na Twoim miejscu rozesłal to CV już teraz.

Dlaczego? Nie mam skończonego projektu żadnego, ciągle coś się znajduje do poprawy na lepsze.

Nic nie tracisz, a możesz zyskać.

Masz rację tak zrobię kończe te testy i pozniej CV i wysyłam

LukaszCh233 napisał(a):

Łatwo się pisze testy które nic nie testują

Ej no mówiłeś, że dobre są

To miała być rada. Jeśli czujesz że pisanie testów sprawia że musisz nad nimi pomyśleć - to dobry znak. Jeśli piszesz testy "od strzała", to prawdopodobnie przyklepują implementacje i są niepomocne.

To ja musze myśleć xD
Dobra dzięki za pomoc jutro bede myślał i pisał te testy jak coś napisze to podeśle

Witam coś stworzyłem

 @Test
    public void quizCategoryInQuizIsChangedWhenUpdateCategory_test() {
        QuizCategory quizCategory = newQuizCategory("testCategory");

        Quiz quiz = newQuizWithCategory("test", quizCategory);

        QuizCategory updatequizCategory = newQuizCategory("testCategoryUpdate");

        QuizCategory updateCategory = quizCategoryService.updateQuizCategory(quizCategory.getId(), updatequizCategory);
        Optional<Quiz> updateQuiz = quizRepository.findById(quiz.getId());


        Assertions.assertEquals(updateCategory.getName(), "testCategoryUpdate");
        Assertions.assertTrue(updateQuiz.isPresent());
        Assertions.assertEquals(updateQuiz.get().getQuizCategory().getName(), "testCategoryUpdate");
    }

I tutaj inne

 @Test
    public void createdQuizWithPublicStatusCanBeFindInGlobalQuizList_test() {
        User user = newUser("test@example.com");
        newQuizWithStatus("test", Status.PUBLIC, user.getEmail());
        newQuizWithStatus("test1", Status.PRIVATE, user.getEmail());

        List<QuizDTO> publicQuizzes = quizService.findAllPublicQuizzes();

        Assertions.assertEquals(publicQuizzes.size(), 1);
    }

    @Test
    public void userCanFindOwnQuizzesWithOtherStatus_test() {
        User user = newUser("test@example.com");
        newQuizWithStatus("test", Status.PUBLIC, user.getEmail());
        newQuizWithStatus("test1", Status.PRIVATE, user.getEmail());

        List<QuizDTO> userQuizzes = quizService.findYourQuizzes(new TestPrincipal(user.getEmail()));

        Assertions.assertEquals(userQuizzes.size(), 2);
    }

    private void newQuizWithStatus(String title, Status status, String email) {
        QuizCategory quizCategory = new QuizCategory(null, "TestCategory");
        quizCategoryRepository.save(quizCategory);

        Quiz quiz = new Quiz();
        quiz.setTitle(title);
        quiz.setUserId(null);
        quiz.setQuizCategory(quizCategory);
        quiz.setStatus(status);
        quizService.createQuiz(quiz.getTitle(), quizCategory.getId(), quiz.getStatus(), new TestPrincipal(email
        ));
    }

    private User newUser(String email) {
        User user = new User(null, "testName", "test@example.com", "password", Role.USER);
        return userRepository.save(user);
    }
}

quizCategoryInQuizIsChangedWhenUpdateCategory_test przekombinowany.
createdQuizWithPublicStatusCanBeFindInGlobalQuizList_test, prawie dobry. Test by też przeszedł gdyby funkcja zwracała tylko prywatne quizy.
userCanFindOwnQuizzesWithOtherStatus_test - nic nie testuje, jakbyś usunął filtrowanie, test nadal przejdzie.

Riddle napisał(a):

quizCategoryInQuizIsChangedWhenUpdateCategory_test przekombinowany.

hmm nie wiem wydaje się takie proste ale okey

createdQuizWithPublicStatusCanBeFindInGlobalQuizList_test, prawie dobry. Test by też przeszedł gdyby funkcja zwracała tylko prywatne quizy.

Jak to przecież zachowanie to wyszukanie listy quizów publicznych wszystkich użytkowników

userCanFindOwnQuizzesWithOtherStatus_test - nic nie testuje, jakbyś usunął filtrowanie, test nadal przejdzie.

a nie testuje wyszukiwania swoich quizow które stworzyłem, czyli quizy zalogowanej osoby?

LukaszCh233 napisał(a):

Riddle napisał(a):

quizCategoryInQuizIsChangedWhenUpdateCategory_test przekombinowany.

hmm nie wiem wydaje się takie proste ale okey

No zastanów się, quizCategoryInQuizIsChangedWhenUpdateCategory_test, czyli jak rozumiem, jak przeniesiesz quiz do innej kategorii, to kategoria quizu powinna się zmienić. Ja napisałbym to tak:

quiz = newQuizInCategory("blue");
moveQuizToCategory(quiz, "green");
assertEquals(quiz.getCategory().getName(), "green");

Banalnie prosty test. Twój jest przekombinowany, i do tego testuje szczegóły implementacyjne.

LukaszCh233 napisał(a):

createdQuizWithPublicStatusCanBeFindInGlobalQuizList_test, prawie dobry. Test by też przeszedł gdyby funkcja zwracała tylko prywatne quizy.

Jak to przecież zachowanie to wyszukanie listy quizów publicznych wszystkich użytkowników

Ale Twój test tego nie testuje. Zmień swój kod, tak że zwraca same prywatne - zobaczysz, że ten test nadal przechodzi (a jakiś powinien sfailować).

LukaszCh233 napisał(a):

userCanFindOwnQuizzesWithOtherStatus_test - nic nie testuje, jakbyś usunął filtrowanie, test nadal przejdzie.

a nie testuje wyszukiwania swoich quizow które stworzyłem, czyli quizy zalogowanej osoby?

Nope.

Usuń filtrowanie, i np. zwróć wszystkie quizy, zobaczysz że test przejdzie, a powinien sfailować.

Riddle napisał(a):

LukaszCh233 napisał(a):

Riddle napisał(a):

quizCategoryInQuizIsChangedWhenUpdateCategory_test przekombinowany.

hmm nie wiem wydaje się takie proste ale okey

No zastanów się, quizCategoryInQuizIsChangedWhenUpdateCategory_test, czyli jak rozumiem, jak przeniesiesz quiz do innej kategorii, to kategoria quizu powinna się zmienić. Ja napisałbym to tak:

Kopiuj

quiz = newQuizInCategory("blue");
moveQuizToCategory(quiz, "green");
assertEquals(quiz.getCategory().getName(), "green");

Znaczy to nie przenosi quizu tylko po prostu jak admin aktualizuje category to quiz tez zmienia na tą kategorie wiec w sumie bez sensu.

Banalnie prosty test. Twój jest przekombinowany, i do tego testuje szczegóły implementacyjne.

LukaszCh233 napisał(a):

createdQuizWithPublicStatusCanBeFindInGlobalQuizList_test, prawie dobry. Test by też przeszedł gdyby funkcja zwracała tylko prywatne quizy.

Jak to przecież zachowanie to wyszukanie listy quizów publicznych wszystkich użytkowników

Ale Twój test tego nie testuje. Zmień swój kod, tak że zwraca same prywatne - zobaczysz, że ten test nadal przechodzi (a jakiś powinien sfailować).

No nie przejdzie bo mam List<QuizDTO> publicQuizzes = quizService.findAllPublicQuizzes(); a to zwraca tylko quizy ze statusem PUBLIC

LukaszCh233 napisał(a):

userCanFindOwnQuizzesWithOtherStatus_test - nic nie testuje, jakbyś usunął filtrowanie, test nadal przejdzie.

a nie testuje wyszukiwania swoich quizow które stworzyłem, czyli quizy zalogowanej osoby?

Nope.

Usuń filtrowanie, i np. zwróć wszystkie quizy, zobaczysz że test przejdzie, a powinien sfailować.

nie powinien przejść bo nie ma takiej możliwości w projekcie, user może wyświetlić tylko swoje testy dzięki autoryzacji czyli za pomoca email nie ważne jaki mają status
Natomiast jeśli chodzi o quizy innych to wyświetlą mu sie tylko te publiczne

LukaszCh233 napisał(a):

No nie przejdzie bo mam List<QuizDTO> publicQuizzes = quizService.findAllPublicQuizzes(); a to zwraca tylko quizy ze statusem PUBLIC

A jak popełnisz błąd podczas refaktoru, i niechcący dodasz ! gdzieś w .findAllPublicQuizzes(), tak że będzie bug że funkcja zwraca tylko prywatne, to jak myślisz, ten test przejdzie czy nie?

LukaszCh233 napisał(a):

nie powinien przejść bo nie ma takiej możliwości w projekcie, user może wyświetlić tylko swoje testy dzięki autoryzacji czyli za pomoca email nie ważne jaki mają status

Zgadzam się że nie powinien, ale przejdzie.

Testy nie są po to żeby przyklepać Twoją implementację; są po to żeby sprawdzić czy kod robi to co ma robić. I niestety na ten moment tego nie sprawdzają Więc niestety ich wartość jest dosyć niska.

Riddle napisał(a):

LukaszCh233 napisał(a):

No nie przejdzie bo mam List<QuizDTO> publicQuizzes = quizService.findAllPublicQuizzes(); a to zwraca tylko quizy ze statusem PUBLIC

A jak popełnisz błąd podczas refaktoru, i niechcący dodasz ! gdzieś w .findAllPublicQuizzes(), tak że będzie bug że funkcja zwraca tylko prywatne, to jak myślisz, ten test przejdzie czy nie?

LukaszCh233 napisał(a):

nie powinien przejść bo nie ma takiej możliwości w projekcie, user może wyświetlić tylko swoje testy dzięki autoryzacji czyli za pomoca email nie ważne jaki mają status

Zgadzam się że nie powinien, ale przejdzie.

W jaki sposób to przejdzie?

Testy nie są po to żeby przyklepać Twoją implementację; są po to żeby sprawdzić czy kod robi to co ma robić. I niestety na ten moment tego nie sprawdzają Więc niestety ich wartość jest dosyć niska.

To ja już nie wiem, nic nie wymyślę lepszego chyba i mam dość tych testów

LukaszCh233 napisał(a):

W jaki sposób to przejdzie?

No popatrz:

@Test
public void createdQuizWithPublicStatusCanBeFindInGlobalQuizList_test() {
  User user = newUser("test@example.com");
  newQuizWithStatus("test", Status.PUBLIC, user.getEmail());
  newQuizWithStatus("test1", Status.PRIVATE, user.getEmail());

  List<QuizDTO> publicQuizzes = quizService.findAllPublicQuizzes();

  Assertions.assertEquals(publicQuizzes.size(), 1);
}

Tworzysz dwa quizy, jeden publiczny, drugi prywatny. Asercja sprawdza że zwrócono jeden quiz. Nie sprawdza czy zwrócono prywatny czy publiczny. Czyli jeśli będzie bug w aplikacji, że Twoja funkcja findAllPublicQuizzes() zwraca prywatne quizy, to ten test tego nie wykryje.

Riddle napisał(a):

LukaszCh233 napisał(a):

W jaki sposób to przejdzie?

No popatrz:

Kopiuj

@Test
public void createdQuizWithPublicStatusCanBeFindInGlobalQuizList_test() {
  User user = newUser("test@example.com");
  newQuizWithStatus("test", Status.PUBLIC, user.getEmail());
  newQuizWithStatus("test1", Status.PRIVATE, user.getEmail());

  List<QuizDTO> publicQuizzes = quizService.findAllPublicQuizzes();

  Assertions.assertEquals(publicQuizzes.size(), 1);
}

Tworzysz dwa quizy, jeden publiczny, drugi prywatny. Asercja sprawdza że zwrócono jeden quiz. Nie sprawdza czy zwrócono prywatny czy publiczny. Czyli jeśli będzie bug w aplikacji, że Twoja funkcja findAllPublicQuizzes() zwraca prywatne quizy, to ten test tego nie wykryje.

A jak dodam asercje żeby sprawdzała publicQuizz.get(0).getStatus, Status.PUBLIC?

LukaszCh233 napisał(a):

A jak dodam asercje żeby sprawdzała publicQuizz.get(0).getStatus, Status.PUBLIC?

Lepiej byłoby dodać asercję na nazwę quizu, coś takiego:

@Test
public void findPublicQuizes() {
  newQuizWithStatus("fruits", Status.PUBLIC);
  newQuizWithStatus("colors", Status.PRIVATE);
  var quizes = quizService.findAllPublicQuizzes();
  Assertions.assertEquals(quizes.size(), 1);
  Assertions.assertEquals(quizes.get(0).getName(), "fruits");
}

Riddle napisał(a):

LukaszCh233 napisał(a):

A jak dodam asercje żeby sprawdzała publicQuizz.get(0).getStatus, Status.PUBLIC?

Lepiej byłoby dodać asercję na nazwę quizu, coś takiego:

Kopiuj

@Test
public void findPublicQuizes() {
  newQuizWithStatus("fruits", Status.PUBLIC);
  newQuizWithStatus("colors", Status.PRIVATE);
  var quizes = quizService.findAllPublicQuizzes();
  Assertions.assertEquals(quizes.size(), 1);
  Assertions.assertEquals(quizes.get(0).getName(), "fruits");
}

i co i już wtedy to bedzie dobry test tylko po dodaniu tej asercji? Bo ja już sie pogubiłem xD teraz tak jakby testuje metode a nie tak jak ty mi mówiłeś, że zachowanie czyli cos sie dzieje jeśli coś sie wydarzy.
przecież to sie nie wiele różni od tego co było tylko no wizualnie lepiej ale zasada taka sama.

@Test
void shouldFindAllPublicQuizzes_Test() {
    //Given
    QuizCategory quizCategory = new QuizCategory(null, "testCategory");
    quizCategoryRepository.save(quizCategory);

    Quiz quiz = new Quiz(null, null, null, quizCategory, null, Status.PUBLIC);
    Quiz quiz1 = new Quiz(null, null, null, quizCategory, null, Status.PUBLIC);
    quizRepository.save(quiz);
    quizRepository.save(quiz1);

    //When
    List<QuizDTO> quizDTOList = quizService.findAllPublicQuizzes();

    //Then
    assertEquals(2, quizDTOList.size());
}

Znajde gdzieś poradnik czy cokolwiek, żeby dobrze zrozumieć testy tak jak ty mi tłumaczysz?

LukaszCh233 napisał(a):

i co i już wtedy to bedzie dobry test tylko po dodaniu tej asercji? Bo ja już sie pogubiłem xD

Test musi spełnić kilka kryteriów, żeby można go było nazwać dobrym:

1. Musi failować, jeśli jest bug
2. Musi przechodzić, jeśli zachowanie jest odpowiednie (nawet jeśli implementacja się zmieni)
3. Czytając test, musi być widać intencje autora

Niektóre Twoje testy cierpią na te choroby - często nie widać co się dzieje (3.), czasem nie failują jak jest bug (1.), i czasem widzę że Twój test jest przywiązany do implementacji (2.).

Są jeszcze inne, z którymi na szczęście nie masz problemu np. muszą być szybkie, i u Ciebie są; za każdym razem ich wynik powinien być taki sam, i u Ciebie są.

LukaszCh233 napisał(a):

Znajde gdzieś poradnik czy cokolwiek, żeby dobrze zrozumieć testy tak jak ty mi tłumaczysz?

Książka "TDD by Example", autora Kent Beck. Jest dosyć tania w empiku.

Ewentualnie tutaj masz PDF: https://www.cs.uic.edu/~i442/Notes/Test%20Driven%20Development%20Excerpt.pdf

Riddle napisał(a):

LukaszCh233 napisał(a):

i co i już wtedy to bedzie dobry test tylko po dodaniu tej asercji? Bo ja już sie pogubiłem xD

Test musi spełnić kilka kryteriów, żeby można go było nazwać dobrym:

1. Musi failować, jeśli jest bug
2. Musi przechodzić, jeśli zachowanie jest odpowiednie (nawet jeśli implementacja się zmieni)
3. Czytając test, musi być widać intencje autora

Niektóre Twoje testy cierpią na te choroby - często nie widać co się dzieje (3.), czasem nie failują jak jest bug (1.), i czasem widzę że Twój test jest przywiązany do implementacji (2.).

Są jeszcze inne, z którymi na szczęście nie masz problemu np. muszą być szybkie, i u Ciebie są; za każdym razem ich wynik powinien być taki sam, i u Ciebie są.

LukaszCh233 napisał(a):

Znajde gdzieś poradnik czy cokolwiek, żeby dobrze zrozumieć testy tak jak ty mi tłumaczysz?

Książka "TDD by Example", autora Kent Beck. Jest dosyć tania w empiku.

Ewentualnie tutaj masz PDF: https://www.cs.uic.edu/~i442/Notes/Test%20Driven%20Development%20Excerpt.pdf

Dobra dzięki zobaczę co tam ciekawego napisał może to mi jakoś rozjaśni.
Czyli kolejny dzień stracony bo stoje w miejscu ale no trudno jutro znowu to samo i wrócę z nowymi propozycjami testów

Proces nauki pisania testów nie różni się od procesu nauki inych rzeczy: potrzebna jest praktyka, stopniowe poznawanie zagadnienia itp. Twój mózg potrzebuje czasu aby nowe informacje przetworzyć i sobie poukładać więc się nie zrażaj.

Czytaj o testach, zadawaj pytania, pisz testy a na pewno będzie coraz lepiej ;-)