[saul]

Mirki, prośba o wyjaśnienie dlaczego źle używam dataProviders w tym przykładzie: https://gist.github.com/anonymous/88399d23a9c2871f76c3

#phpunit #tdd #programowanie

[MacDada]

@saul:

0. Nie podałeś na czym polega błąd, sam productProvider() wygląda ok.

11: Użyj typehint na array dla pewności, że dobry rodzaj danych przychodzi

13: Nie pokazałeś co robi mockTransitory()
44: Niezainicjalizowana zmienna $productArr

[saul]

@MacDada: trochę wyciąłem na potrzeby posta. To co zostało mi zarzucone to (mniej więcej) cytat: "twój dataProvider buduje test a dataProvider powinien dostarczać dane do zbudowanego testu". Nie czuję tego kompletnie. Wstępnie myślałem, że chodzi o sygnaturę metody i powinna być testAdd($product, $quantity, $expectedQuantity). Ale to jeszcze coś innego, głębszego ( ͡° ͜ʖ ͡°)

[MacDada]

@saul: W razie wątpliwości czy poprawnie zagnieździłeś arraye, rozpisz to sobie do zmiennych:

public function productProvider()
{
        $item1 = [
                'product' => $this->productFactory(0),
                'quantity' => 10,
        ];
        $item2 = [
                'product' => $this->productFactory(1),
                'quantity' => 6,
        ];


        $example1Arg1_productArr = [$item1, $item2];
``````
        $example1 = [$example1Arg1_productArr];
``````
        $examples = [$example1];
``````
        return $examples;
}


[MacDada]

@saul: Czyli ogólnie działa (testuje), tylko ktoś uważa, że test powinieneś inaczej napisać (w inny sposób użyć dataprovidera)?

[saul]

@MacDada: dokładnie. Źle ideologicznie wykorzystuję dataProviders. Powiedziały mi to dwie niezaleźne osoby, które są seniorami. Jedna na rekrutacji, a druga to dobry znajomy, od którego się już dużo nauczyłem, więc mam do niego zaufanie.

[MacDada]

@saul: Na moje oko jest dobrze – sam też w ten sposób piszę dataProviderów. Jak więc dowiesz się co jest źle, daj znać ;-)

[saul]

@MacDada: Wydaje mi się, że chodzi o to, że aktualny data provider zwraca dane, które nie są istotną częścią testów. W tym wypadku przekazuję w providers interfejs Product, ale nie jego testuję. Testuję quantity, więc tego powinno się oczekiwać od providera. W skrócie, zbyd duża i niepotrzebna odpowiedzialność tej metody, nieadekwatna do sytuacji.

[MacDada]

@saul: Ja staram się tak przygotować DataProviderów, żeby móc bezpośrednio wykorzystać je w metodzie testującej.

Czyli właśnie dostarczam bezpośrednio Product, a nie same dane do jego utworzenia.
Nie wydaje mi się, żeby to było jakimś większym błędem, chyba, że metoda testująca jest wtedy mniej czytelna.

Tak więc nie uznawałbym tego za błąd, tylko co najwyżej inną filozofię, może kwestię gustu? Chętnie zmienię zdanie jeśli mi ktoś wyjaśni dlaczego Product nie

[saul]

@MacDada: bo tak naprawdę nie to jest meritum testu. W tym wypadku testuję poprawność dodawania przedmiotów do koszyka. Zmienną (testowaną) w tym wypadku jest liczba produktów a nie sam produkt (interfejs produktu). Teraz myślę, że wystarczyłby mock ProductInterface aby to dobrze przetestować.

[MacDada]

@saul: Czyli dylemat każdego testu:

* totalna izolacja – same mocki, stuby, test doubles
* trochę interakcji z innymi prawdziwymi obiektami – bardziej funkcjonalnie, ale jak Product się zepsuje, to i ten test wybuchnie

Ciężko mi powiedzieć co lepsze w tym przypadku, osobiście podmieniam implementacje usług (z reguły mają wiele dodatkowych zależności), ale np encje czy value objects przekazuję „prawdziwe”.