Czy piszecie testy dla śmiesznie prostych klas?

Powiedzmy mamy taki kod, co z nim robicie? Piszecie test, czy olewacie?

class SystemIntegrationMenuTab
{
    /** @var string */
    private $url;
    /** @var string */
    private $identifier;

    public function __construct($url, $identifier) {
        $this->url = $url;
        $this->identifier = $identifier;
    }

    public function getUrl() {
        return $this->url;
    }

    public function getIdentifier() {
        return $this->identifier;
    }
}

Ja jak robię taką klasę to olewam test, bo moim zdaniem nic nie wnosi. Dopiero jak do klasy dojdzie jakaś logika to tworzę testcase'a (jeżeli nigdy nie będzie logiki to klasa jest forever untested).

imo testy powinny niesc ze soba jakas wartosc.

Nie widze potrzeby pisania testow dla samej idei pisania testow. Jezeli nie ma logiki ktorej mozna testowac to czegos takiego nie testuje

To nie ma sensu.
Poprawność tego kodu można stwierdzić w kilkanaście sekund. Jeśli gdzieś jest głupi błąd (np. pola zamienione) to wyjdzie na jaw tam, gdzie klasa jest użyta - i tam test już by się przydał.

Może się opisałem problem, głównie chciałem spytać jak ustalacie jak prosta musi być klasa żeby test był niepotrzebny? Jak mam tylko konkatenację stringów to też olewam, ale gdzie macie limit?

Zasada w TDD jest taka, że kod który nie jest wymagany przez testy nie powinien w ogóle istnieć. Metody nie muszą być testowane bezpośrednio, ale powinny być w ogóle wykonane podczas testów. Nie wszystko jest też sens testować testami jednostkowymi - np kodu, który wywołuje java.lang.System.exit(int). Taki kod powinien być pokryty w innych rodzajach testów.

http://practicalunittesting.com/btgt.php

Co do zasady to testuję tylko publiczne metody które coś ciekawego robią, oraz funkcje(bez efektów ubocznych), bo testy są banalne, a zawsze to jakaś dodatkowa informacja.

imo nie ma sensu testowania takich klas, szkoda czasu i energii, no chyba ze daja ci premie od pokrycia kodu testami ;)
osobiscie pisze testy jednostkowe praktycznie wylacznie do bardziej skomplikowanych algorytmow, reszta jest sprawdzana przez testy integracyjne.

@TomRiddle przed napisaniem testu zadaj sobie pytanie co chcę tutaj sprawdzić/przetestować. Bo w twoim kodzie nie ma nic ponad konstrukcje języka. Chcesz przetestować czy return x zwróci x? :) No chyba że masz kasę na 17 parametrów konstruktora, wszystkie tego samego typu i chcesz się upewnić ze dobrze przypisujesz parametry do pól, ale wtedy testy są raczej twoim najmniejszym zmartwieniem ;)

Dla języka silnie typowanego (Java, C++) nie ma sensu, bo kompilator wyłapie wszystkie pomyłki w geterach / seterach.
Dla PHP-a możliwe że bym zrobił jeden test.

Testy oprócz testowania logiki biznesowej pełnią też funkcję dokumentacyjną.

Jest jedna, bajecznie prosta zasada:
NIGDY nie testuj klas, **metod **itp. :O!

Jeśli testujesz to tylko funkcjonalności - np. metoda **pracownikMiesiaca ** ma zwracać pracowanika miesiąca (czyli jak podam takie dane to zwrócić ma Jurka) -> Test. Jak podam pusty plik - to ma obrazić mojego kota ->Test. W ramach pracy nad tą metodą możesz schodzić niżej (podmoduły) i testować : jak podam taki plik - to ma odczytac takie nazwiska ->Test.

Nie wierzę że muszę 3ci raz mówić o co chodziło w temacie... Nie pytałem co/jak testować tylko jak WY to robicie? Nie szukałem rad.

Ciągle się nie dowiedziałem btw.

Ja testuję logikę. To co pokazałeś to wygląda jak zwykły worek na dane, DTO czy ViewModel... takich rzeczy nie testuje. Jak by tam była jakaś logika w tworzeniu obiektu, to bym to przetestował. Guardów typu sprawdzenie czy argument nie jest nullem mimo że to pewna "logika" też nie testuje jednostkowo. Zwłaszcza, że to można zaimplementować w zależności od technologii na kilka sposobów, od ifów, przez kontrakty na specjalnych klasach typu Fail.IfNull() kończąc.
Edytka dodaje: (jeżeli guardy wynikały by z logiki biznesowej i rzucały by odpowiednimi wyjątkami, to przetestował bym je jako corner casy, b były by częscią logiki, a nie częścią specyfikacji języka jak np nullowalność obiektów).

Jak już zostało wspomniane, można to przetestować integracyjnie w miejscu użycia, nie jako przy okazji. A i to niekoniecznie, bo zależnie gdzie by się znajdował, mógłbym też jeśli było by to jakieś DTO czy ViewModel, co najwyżej go w testach integracyjnych tworzyć, żeby wrzucić jako parametr do testowanej metody.

Co bym przetestował, gdzie jest moja granica? Gdy np identifier był w jakiś sposób zmieniany, np jeśli jest nullem albo pustym stringiem to przypisz mu X (nie ważne czy w konstruktorze, czy getterze ta logika by się znalazła, to już inna kwestia gdzie taką logikę umieścić, w konstruktorze czy getterze). To byłby jednocześnie wartościowy test chroniący przed regresją i dziwnymi problemami jak i forma dokumentacji kodu (co testy powinny też robić).