nos vs pytest - jakie (subiektywne) różnice też powinny mnie skłonić? [Zamknięte]

Zacząłem pracować nad dość dużym (wielowątkowym) projektem w Pythonie, z mnóstwem (jednostkowych) testów. Najważniejszym problemem jest to, że uruchomienie aplikacji wymaga wcześniej ustawionego środowiska, które jest realizowane przez menedżera kontekstu. Do tej pory korzystaliśmy z poprawionej wersji modułu uruchamiającego testy jednostkowe, który uruchamiałby testy wewnątrz tego menedżera, ale nie pozwala na przełączanie kontekstu między różnymi modułami testowymi.

Zarówno nos, jak i pytest obsługują taką rzecz, ponieważ obsługują mocowania na wielu ziarnistościach, więc szukamy przełączenia na nos lub pytest. Obie te biblioteki obsługiwałyby również testy „tagowania” i uruchamiały tylko te oznaczone podzbiory, co również chcielibyśmy zrobić.

Przeglądałem trochę dokumentację zarówno nosa, jak i pytesta i, o ile widzę, większa część tych bibliotek zasadniczo obsługuje tę samą funkcjonalność, z tym że może mieć inną nazwę lub wymagać nieco innej składni. Zauważyłem też drobne różnice w dostępnych wtyczkach (nos obsługuje wiele procesów, na przykład pytest nie wydaje się)

Wydaje się więc, że diabeł tkwi w szczegółach, co oznacza (przynajmniej często) w osobistym guście i lepiej wybrać bibliotekę, która najlepiej pasuje do naszego gustu.

Chciałbym więc poprosić o subiektywną argumentację, dlaczego mam iść z nosem lub zapytać o to, aby wybrać kombinację biblioteka / społeczność, która najlepiej odpowiada naszym potrzebom.

python pytest nose

— Jakob van Bethlehem
źródło

Po prostu zauważyłem, że mniej więcej to samo pytanie zadano również tutaj - ale to pięć lat temu, więc nadal uważam, że ponowne zadanie pytania ma sens

— Jakob van Bethlehem

pytestobsługuje obsługę wielu procesów za pośrednictwem wtyczki pytest-xdist .

— Bruno Oliveira

Nawiasem mówiąc, menedżery kontekstu są po prostu zwykłymi obiektami Pythona i możesz wywołać manager.__enter__()swoje TestCase.setUp()i manager.__exit__()swoje tearDown().

— rescdsk

Nos nie jest już konserwowany .

— toasted_flakes

Kiedyś używałem Nosa, ponieważ był domyślny w przypadku Pylonów. W ogóle mi się to nie podobało. Miał wąsy konfiguracyjne w wielu miejscach, praktycznie wszystko wydawało się być zrobione za pomocą nieudokumentowanej wtyczki, co czyniło wszystko jeszcze bardziej pośrednim i zagmatwanym, a ponieważ domyślnie wykonywał niezatwierdzone testy, regularnie zrywał ze śladami Unicode, ukrywając źródła błędów.

Jestem bardzo zadowolony z py.test przez ostatnie kilka lat. Będąc w stanie tylko napisać test z assertwyjęciu z pudełka sprawia, że cierpię pisania testów sposób mniej, i włamania cokolwiek muszę szczycie rdzeń jest całkiem proste. Zamiast stałego interfejsu wtyczki ma po prostu stosy haków i całkiem zrozumiały kod źródłowy, gdybyś musiał szukać dalej. Napisałem nawet adapter do uruchamiania testów Testify w ramach py.test i miałem więcej problemów z Testify niż z py.test.

To powiedziawszy, słyszałem, że nos ma obecnie wtyczki do testów bezklasowych i potwierdzania introspekcji, więc prawdopodobnie poradzisz sobie z jednym z nich. Nadal czuję, że mogę uderzyć w ziemię z py.test i rozumiem, co się dzieje, gdy się zepsuje.

— Eevee
źródło

Pewne problemy z ukrywaniem śladów zostały naprawione wokół nosa 0.11, wiele lat temu. Ponieważ port Python 3, spodziewam się, że wszystkie dane śledzenia Unicode są rzadsze (chociaż osobiście uważam, że tylko raz napotkałem problem z Unicode z nosem, który pojawił się podczas łączenia go z klasą bazową przypadku testowego, która zrobiła jakąś "sztuczkę", która nie zadziałała naprawdę ma sens - więc okazało się, że nie jest to wina nosa). Podejrzewam, że tak naprawdę oba narzędzia miały szorstkie krawędzie strącane przez lata, więc może spodoba ci się najbardziej to, z czego ostatnio korzystałeś ;-)

— Croad Langshan

co z ostatnią częścią dokumentacji. Nie wiem też, czy używać nosetests czy py.test. oba wydają się być równie dobre, ale jak czytałem, większość ludzi używa obecnie testów nosa. Jaki może być powód, dla którego py.tests ma lepszy zestaw bibliotek wieloprocesorowych?

— proprius

@proprius może być tak, że najpierw były testy nosowe. niektóre frameworki dodały wsparcie dla niego, projekty używające tych frameworków domyślnie go używały i rozprzestrzeniały się. Ponadto, chociaż py.test może powodować katar i testy unittest, jego zwykły styl nie jest dostosowany do klas, więc przeniesienie do py.test może wydawać się zniechęcające.

— Eevee,

Zacząłem czytać część dokumentacji pytest i zdałem sobie sprawę, że w przypadku wieloprocesorowego przetwarzania, a także w zakresie uczenia się dla noworodka, pytest jest lepszym wyborem.

— proprius