[C.....y]

@Khaine: Nie robisz czasem w ASP .NET Core? Obczaj sobie MSowy framework do testów integracyjnych. Przyjemnie pokrywa się nim główne scenariusze użycia i jednocześnie stanowi bardzo fajny feedback loop do developmentu i debugowania.

[Khaine]

@Czesiowcy: Trzaskam w XUnicie obecnie. To tak naprawdę dokumentacja "dobra, taki scenariusz mam zrobiony i sprawdzony", aniżeli jakiekolwiek TDD.

[zibizz1]

@Khaine: popieram twoje podejście. Tylko nie przekreślam unit testów. Zazwyczaj używam do funkcji ktore przetwarzają jakoś informacje albo w określony sposób na podstawie danych wejściowych zwracają wynik czyli dostaje polecenie jak ma działać algorytm który wyszukuje wolne miejsce w harmonogramie dnia i zazwyczaj każdy punkt w takiej dokumentacji to przynajmniej jedej zestaw danych wyjściowych do testów. Trochę bez sensu jest testować czy funkcja AddUser wywoła insert na bazie ale ma

[C.....y]

@Khaine: xUnit to runner do testów, nie zbuduje Ci instancji aplikacji w pamięci i nie wystawi dedykowanego http clienta. Używamy go w kombinacji z frameworkiem do testów integracyjnych ASPa Core i Fluent Assertions/AutoFixture dla czytelności i szybkości trzaskania testowych danych i bardzo dają radę.

[mch0588]

W .Net Core jest coś takiego jak WebApplicationFactory (https://docs.microsoft.com/en-us/aspnet/core/test/integration-tests?view=aspnetcore-2.2). Dostajesz HttpClienta i możesz w testach wysyłać requesty do swojej aplikacji postawionej w pamięci. Do tego testowa baza na dockerze + automatyczne migracje i jest mega.

[Khaine]

Tylko nie przekreślam unit testów.

@zibizz1: Ja widzę zastosowanie w unit teście gdy mamy jakiś faktycznie algorytm który chcemy przetestować. Dajesz mu np. graf X i ma znaleźć najkrótszą drogę. W takim przypadku gdy algorytm ma jedno wejście i jedno wyjście i jest pojedynczą funkcją oderwaną od reszty świata, wynik daje wartościową informację że coś działa - i jak nawrzucamy mu takich grafów z 50 w różnych losowych i chamskich kombinacjach,

[C.....y]

@Khaine: Na litość niebios, ja i kolega @mch0588 mówimy o tym samym

[C.....y]

@Khaine: a w ogóle skąd ta alternatywa? Albo to, albo xUnit? Testy Integracyjne mogą używać takiego runnera/frameworka testowego, jaki sobie umaisz, xUnit, NUnit, MSTest, to tam lubisz. Jakoś trzeba je przecież odpalić

[Khaine]

@Czesiowcy: No tak, tylko obecnie w xUnit sam sobie buduję kontroler z kontekstem i zapiętym wszystkim w stanie rzeczywistym - choć na testowej bazie danych. A potem odpalam funkcję kontrolera jak zwykła funkcję i sprawdzam czy dobrze zwraca.

[k.....n]

@Khaine jeżeli do unit testów potrzebujesz mockować tyle rzeczy, to to prawdopodobnie nie są prawdziwe unit testy Kontrolerów unit testami przeważnie nie przetestujesz (chyba, że jakieś private/protected metody obiektu). W takim RSpec (nie miałem styczności z c#, więc się na ten temat nie wypowiem) masz bardzo podobne controller testy i request testy. Gdy tworzę projekt w railsach to testuję kontrollery przede wszystkim request testami. Po prostu swego rodzaju małe scenariusze dla

[Khaine]

Gdy tworzę projekt w railsach to testuję kontrollery przede wszystkim request testami. Po prostu swego rodzaju małe scenariusze dla pojedynczych endpointów/mutacji lub query w graphql, gdzie sprawdzam między innymi response czy zmiany w DB

@kuskoman: No w praktyce robię dokładnie to samo. Tylko nie jest to pełen request, a odpalenie funkcji w kontrolerze. Pomijam walidację tokenów i czy użytkownik ma dostęp - bo w scenariuszu zakładam, że po prostu ma

[k.....n]

@Khaine zawsze możesz zrobić sobie helper valid_headers z tokenem authorizantion i robić scenariusze
describe something
context when valid headers are being passed
context when auth headers are invalid

[Khaine]

@kuskoman: Nie jestem pewien czy to jest w ogóle sens sprawdzać tysiące razy. Mechanizm który za tym stoi jest generalnie prosty i badany na wyrywki po prostu działał, a działa dokładnie tak samo dla każdej funkcji każdego kontrolera.