Hejka,
bawie sie teraz z Behat. Do tego podpinam jeszcze mink oraz selenium by testowac stronke normalnie w przegladarce.
w pliku .feature mam nastepujacy scenariusz

To pieknie dziala. Loguje sie jako ja i widzi na stronie to co powinno wiedziec. Bajka.
No ale teraz chcialbym by to testowali tez moi koledzy z teamu. Nie chce jednak komitowac moich danych logowania. Kazdy ma swoje. Idzie jakos w miejsce loginu i hasla wstawic jakies zmiennej srodowiskowe tudziez jakies wartosci z konfiguracji behat.yml ?

Testujesz czy dla zalogowane użytkownika coś się pokaże, nie uzależniaj wyniku testu od tego, czy ktoś ma akurat takiego usera czy nie, lub czy ma konfiguracje login/pass czy nie ma. Test ma sprawdzić, czy dla zalogowanego użytkownika coś pokaże, więc niech tylko to robi. Najlepiej w Background najpierw stwórz takiego użytkownika.

@Damonsson tak wiem, ja to rozumiem. Ale

1) W aplikacji, ktora akurat testuje, stworzenie uzytkownika nie jest takie proste. Dlugo by gadac. Tak czy siak potrzebuje zalogowac na istniejacego juz uzytkownika
2) Tych parametrow potrzebuje tez dla rzeczy, wiec nawet jesli bym stworzyl uzytkownika, to nadal potrzebuje parametryzacji do innych celow. idzie to zrobic?

@nospor nie wiem co dokładnie masz na myśli mówiąc, że "W aplikacji, ktora akurat testuje, stworzenie uzytkownika nie jest takie proste.", ale prawdopodobnie mówisz o całym procesie rejestracji. W teście chcesz jedynie zapewnić istnienie użytkownika w bazie. Nie używasz całej fasady rejestrującej użytkownika łącznie z wysyłanym powiadomieniem na maila itd Przykład: https://github.com/pyrorules/rest-api/blob/...roducts.feature

Ale załóżmy, że jednak zapisanie użytkownika to jednak jest jakiś kosmos, 1000 powiązań niemogących istnieć niezależnie od siebie (wtedy byłby zły design though). W takim przypadku możesz zrobić jedną dyrektywę typu "Given that default users are registered", a ta dyrektywa np. działa jak fixtures. Przykład: https://github.com/pyrorules/rest-api/blob/...M/LoadUsers.php . Wtedy każdy developer może z nich czytelnie korzystać.

@pyro no wlasnie tutaj autoryzacja usera leci do zupelnie innej strony z inna baza danych i totalnie z innym wszystkim.
Dzieki za twoje repo, wyglada ciekawie i moze posluzyc za niezly przyklad w innych "normalnych" aplikacjach

Możesz dokładniej określić jak następuje autoryzacja poprzez serwis zewnętrzny? To jest coś w stylu mikroserwisu?

Mamy stronke main.co.uk
Mamy stronke auth.co.uk

Gdy wchodze na stronke main.co.uk i nie jestem jeszcze zalogowany, zostaje przekierowany na auth.co.uk, gdzie moge sie zalogowac przez normalny formularz logowania. Stronka auth.co.uk trzyma sesje logowania.
Po zalagowaniu zostaje ponownie przekierowany do main.co.uk, tam w php przez curl pobieram info z auth.co.uk czy jestem zalogowany czy nie, pobieram role itp. Dzieki temu na main.co.uk wiem co moge wyswietlac itp.

Od biedy moglbym sie laczyc z baza auth.co.uk i tam tworzyc tego usera, jednak naprawde wolalem tego uniknac.

ps: nie, ja tego nie projektowalem. Jak przyszedlem to juz tak bylo.

No cóż... jak sam zauważyłeś zasada działania mogłaby być lepsza No ale nawet w takich wypadkach łatwo sobie poradzić.

Niech ten serwis, do którego słany jest request cURL'owy będzie po prostu mockiem.

// EDIT

I wtedy w configu testowym podmieniasz adres na Twojego mocka. Tutaj przykład z bazą danych: https://github.com/pyrorules/rest-api/blob/...config_test.yml

Tak, w kodzie php bez problemu moge zrobic mock.
Tutaj jednak uzywam tylko i wylacznie scenariusza w postaci tekstu. Calos chodzi na Selenium. Za bardzo nie wiem jak moglbym w takim wypadku wciac sie gdzies w srodek i zrobic z auth.co.uk mock.
Jakies wkazowki?

ps: chyba ze chodzilo ci, bym pod adresem mock.auth.co.uk postawil mini appke, ktora bedzie zwracac co ma zwracac od tak na sztywno?

edit
Acha, czyli tak ja przypuszczalem, mam stworzyc serwis mock. No jest to jakas idea Pytanie tylko czy warta swieczki... Narazie stworzylem testowego usera, ktory ma byc i koniec (tak wiem wiem )

Wyedytowałem na coś z przykładem.

A na pytanie "Czy gra warta świeczki" odpowiadam tak:
- Wiele osób słysząc o mockach chyba wyobraża sobie, że mają pisać oddzielną aplikację o dużej złożoności. A budowa jest prosta jak budowa cepa. Routing i zwracanie odpowiedzi: Dany endpoint zwraca taką a taką odpowiedź. Nie ma tu skomplikowanej logiki tylko proste opisywanie zwracanych danych
- Podejście "ten użytkownik ma być i już" często rodzi później wiele praktycznych problemów, które ciężko opisać słownie i trzeba samemu je odczuć na własnej skórze
- Co jak piszesz appkę, a serwis padnie albo będzie edytowany przez jego developerów?
- Coś podobnego będziesz robił również w przypadku zmieniających się danych? Co jak ktoś będzie testował zmianę hasła? Twoje testy później nie zadziałają i będą sypać błędami

Popelnilem blad, bo stwierdzilem, ze musze zrobic mock dla calej sciezki, czyli musze miec formularz logowania, potem submit tego forma i takie tam.
A ja przeciez moge zrobic poprostu mockup zwracania info czy user jest zalogowany czy nie i do formularza logowania w ogole nie dojdzie. I wowczas faktycznie skraca sie to do banalnego routing z z banalna odpowiedzia. Dzieki

[minelo pare sekund]
Po namysle jednak w ten sposob bede mial problem by przetestowac rozne scenariusze z roznymi rolami. Jak w ten sposob mialbym powiedziec dla mockup, ze chce sie zalogowac jako user z dana rola? Chyba jednak bez symulacji formularza logowania tez sie nie obejdzie. Chyba ze dodam jakis trigger w aplikacji main ale to chyba nie bedzie zbyt ladne.


Oczywiscie masz racje i zdaje sobie z tego sprawe. Mam tez jednak ograniczenie czasowe. I tak juz "lekko" wymusilem na szefie troche czasu dla mnie na Behat
Nie zmienia to jednak faktu ze docelowo zrobie mockup z auth - z bardzo prostej przyczyny - mamy bodajze 5 aplikacji i kazda z nich korzysta z aplikacji auth. Chcac porobic testy dla kazdej aplikacji predzej czy pozniej musze i tak miec mockup auth

Ale przecież nic się nie zmieniło? Zobacz jeszcze raz na to: https://github.com/pyrorules/rest-api/blob/...M/LoadUsers.php i na to https://github.com/pyrorules/rest-api/blob/...roducts.feature ? So użytkownicy o różnych uprawnieniach? So.

W Twoim mocku po prostu sobie robisz tablicę użytkowników jakich chciałbyś mieć (może ona być w configu czy gdziekolwiek) i później w Twoim roucie:

[PHP] pobierz, plaintext 
foreach($users as $user) {
    if($user['username'] === $username && $user['password'] === $password) {
        // odpowiedz dla istniejacego uzytkownika
    }
}
 
// odpowiedz dla nieistniejącego usera
[PHP] pobierz, plaintext 

20 sekund roboty do napisania

Ale jak mam do mock przekazac $username i $pasword? Tylko przez formularz, prawda?
Bo to ze napisze to w background to chyba mi tego nie ustawi w zmockowanym auth? Czy moze jednak?

Tak jak ja ustawiłem tutaj: https://github.com/pyrorules/rest-api/blob/...config_test.yml

żeby zamiast do db leciało z zapytaniami do db_test tak Ty masz ustawić, żeby zamiast do auth.co.uk leciało do auth.mock.loc

Ja to rozumiem.
Ja sie pytam, jak mam powiedziec temu auth.mock by mi raz zwrocilo usera z rola1 araz user z rola2 By to zrobic nadal musze miec formularz w auth.mock, prawda?

Nie rozumiem pytania, jak sobie w tablicy konfiguracyjnej wpiszesz np:

[PHP] pobierz, plaintext 
[
            [
                'username' => 'demo',
                'password' => 'demo123',
                'email' => 'demo@post.com',
                'groupRoles' => ['ROLE_USER']
            ],
            [
                'username' => 'demo_admin',
                'password' => 'demo_admin123',
                'email' => 'demo_admin@post.com',
                'groupRoles' => ['ROLE_USER', 'ROLE_ADMIN']
            ]
        ];
[PHP] pobierz, plaintext 

To:
- dla demo / demo123 zwróci użytkownika z rolą usera
- dla demo_admin / demo_admin123 zwróci użytkownika z rolą administratorską

Czyli z inną rolą

No to w takim razie ja chyba nie kumam jeszcze idei tych features co zaprezentowales. Bede musial usiasc na spokojnie i przeanalizowac twoje repo dokladnie jeszcze raz

edit:
ok, piszac usera z rola rola1 mialem na mysli wszystko, login i password rowniez. Zeby mi dla usera demo/demo123 zwrocilo dana role, to musze gdzies okreslic tego usera dla auth.mock. Zeby to gdzies okreslic to musze miec formularz w auth.mock by moc tam wpisac login i haslo, prawda? O to sie wlasnie pytam.

Bo na poczatku pomyslalem, ze zmokuje tylko metody, ktore wysyla main by sie zapytac auth o authentykacje usera, ale nie moge tylko tego zrobic, bo wpierw auth.mock musi wiedziec jakiego usera ma mi zwracac. Do tego potrzebny wiec mi bedzie nadal formularz
Tak, to nie problem stworzyc banalny formularz. Ot, tylko na poczatku myslalem ze sie obejdzie bez

Broń Boże zmieniać jakiekolwiek metody w Twoim serwisie main. To ma być dla Ciebie czarna skrzynka. W środku absolutnie nic nie zmieniasz. Masz mieć pewność, że system działa dobrze w takiej formie, w jakiej jest napisany. Jedynie Twój serwis auth ma być mockiem.

Alez ani przez moment mi nie przyszlo do glowy by to robic. Skad ten pomysl?
Ciezko sie czasami dogadac przez net. Trzeba jak nic kiedys spotkac sie przy piwku

Wczoraj wieczorem siedzialem nad twoim api co pokazales. Fajnie to wyglada - mowie o testach, bo na tym sie skupilem.
Zaczalem to wprowadzac do mojego jednego prywatnego serwisu. Tam na szczescie moglem stworzyc baze testowa, a ze pracuje na symfony to bylo to 10 sekund roboty. Stworzylem background jak to pokazales i faktycznie elegancko to sie sprawuje. Teraz kazdy kto bedzie czytal scenariusz nie bedzie musial sie zastanawiac co sie dzieje. Bajka

Takze jeszcze raz dzieki za dyskusje