Jest jakiś prosty sposób, żeby zaznaczyć wszyskie nieudane testy i usunąć je z aktualnej sesji?
W tym momencie jedyne rozwiązanie jakie widzę to lista nieudanych, rozwinięcie wszystkich klas, metod i przypadków, a następnie ręczne zaznaczenie. Potem ewentualnie import/export tej sesji.
Proszę nie pytajcie dlaczego chcę to zrobić :D
Ale po prostu chcesz tych nie udanych nie widzieć podczas uruchamiania następnych?
@TomRiddle: Sprawa wygląda tak, że ktoś pcha na master kod wywalający kilkadziesiąt testów spośród tysięcy. CI w tym projekcie póki co działa średnio.
Po zrobieniu pull chciałbym sprawdzić, które testy wywala i usunąć je z sesji, tak aby zostały tylko te poprawne. Wtedy odpalając testy widzę, że mój kod nie wywala żadnych z tych działających. Mógłbym też sprawdzać czy liczba testów failed jest stała, ale wtedy ciężko będzie znaleźć, który jest dodatkowy.
Oczywiście jest pewne ryzyko, że mój kod przypadkiem wywala akurat jeden z testów, które wyrzuciłem z sesji, ale liczę na to, że sprawa się rozwiąże jak będę robić PR :D
chalwa napisał(a):
@TomRiddle: Sprawa wygląda tak, że ktoś pcha na master kod wywalający kilkadziesiąt testów spośród tysięcy.
What the fuck?
No to ja bym Ci radził - nie branchuj swojego feature brancha z tego gówna, tylko odbij się od brancha który jest jeszcze stabily. Jak nie ma takiego brancha, to odbij się od commita który nie ma failujących testów (np rób checkout co commit w tył i sprawdź gdzie testy nie failują), a potem na sam koniec merguj do mastera
Ale szczerze mówiąc to to jest pojebane że ktoś wrzuca na główny branch niestabilną wersje :|
Co do Twojego problemu, myślę, że jeśli pracujesz w środowisku w którym cały czas failują testy to niestety zasługujesz na to co masz :D To co możesz zrobić, to do tych testów które failują dodać po prostu skipa, i nie włączać ich. No bo skoro one i tak failują, i i tak jest przyzwolenie na to, to one dla Ciebie są wręcz bezwartościowe. Tak samo jak bezwartościowa jest stabilność aplikacji w której failujące testy "po prostu failują".
Może warto się zastanowić czy skoro failują i jest na to przyzwolenie, to czy nie warto ich usunąć, bo nic nie wnoszą? Np failują mimo tego że aplikacja działa.
@chalwa: No to jeszcze może być tak, że one normalnie przechodzą, tylko failują u Ciebie, bo nie masz czegoś postawionego albo skonfigurowanego.
Test explorer wbudowany w Visual Studio ma opcję, żeby zaznaczyć tylko poprawne testy. Trzeba kliknąć na zielony ✔ a następnie run all tests in view. Temat do zamknięcia.
TomRiddle napisał(a):
chalwa napisał(a):
@TomRiddle: Sprawa wygląda tak, że ktoś pcha na master kod wywalający kilkadziesiąt testów spośród tysięcy.
What the fuck?
No to ja bym Ci radził - nie branchuj swojego feature brancha z tego gówna, tylko odbij się od brancha który jest jeszcze stabily. Jak nie ma takiego brancha, to odbij się od commita który nie ma failujących testów (np rób
checkoutco commit w tył i sprawdź gdzie testy nie failują), a potem na sam koniec merguj domasteraAle szczerze mówiąc to to jest pojebane że ktoś wrzuca na główny branch niestabilną wersje :|
W moim obecnym projekcie był podobny problem.
Przejąłem Jenkins i bitbucket.
Zablokowałem wszystkim dostęp do master/main.
Merge do master/main można zrobić tylko po tym jak Jenkins zgłosi poprawność brancha i są co najmniej dwie akceptacje PR od innych developerów.
Teraz jest miło i przyjemnie (no prawie ale różnica jest ogromna i dyscyplina w zespole większa).
Wysiłek włożony w zmianę konfiguracji zwraca się bardzo szybko i cały zespół chwali sobie takie rozwiązanie.
Nawet jeśli twój proces budowania projektu i uruchamiania testów, jest skomplikowany a wiedza, o Jenkins i bitbucket niewielka, przez co trzeba poświęcić 2 tygodnie na zrobienie tego (lub nawet 4 tygodnie) to i tak warto. Czas i nerwy zwrócą się z nawiązka w 2 miesiące.
MarekR22 napisał(a):
W moim obecnym projekcie był podobny problem.
Przejąłem Jenkins i bitbucket.
Zablokowałem wszystkim dostęp domaster/main.
Merge domaster/mainmożna zrobić tylko po tym jak Jenkins zgłosi poprawność brancha i są co najmniej dwie akceptacje PR od innych developerów.
Hmm, no nie wiem.
Ja bym raczej podszedł socjalnie do problemu, i wymusił najpierw dyscyplinę na zespole. A za każdy commit failujący testy na masterze jeden banan mniej na owocowych czwartkach.
Skala tego projektu jest za duża, żebym miał cokolwiek do powiedzenia na ten temat :D Z tego co widzę to zespół trzyma dyscyplinę i nasz kod ma porządne review. Co do innych zespołów nie wiem, ale się domyślam.
Zgadzam się z @MarekR22 i gdybym zaczynał nowy projekt to była by to rzecz, od której bym zaczął.
chalwa napisał(a):
Skala tego projektu jest za duża, żebym miał cokolwiek do powiedzenia na ten temat :D Z tego co widzę to zespół trzyma dyscyplinę i nasz kod ma porządne review.
Oh really? bo ja swoje całe życie nie widziałem na prawdę dobrego review.
Bo jeśli mówiąc "porządne review", masz na myśli to że ktoś developuje feature kilka dni, a reviewer robi pulla, czyta kod przez 15 minut, i daje okejkę? Bo to jest szukanie literówek a nie review.