@Aventus: co to jest te "live unit testing"?

@scibi_92: że za każdym razem jak dokonujesz zmiany w kodzie to testy się automatycznie wykonują. Są pewne komercyjne narzędzia które potrafią wykryć i uruchomić tylko te testy, które mają pokrycie z kodem w którym dokonano zmian.

@Aventus: Rozumiem, chociaż osobiście nie widzę w tym sensu żeby za każdym razem się wykonywały. Jeśli coś zmieniam żeby to miało ręcę i nogi to nie jest to dodanie jednego pola, albo zmiana nazwy jednej zmiennej.

A to ciekawe. Ja korzystam z tego nagminnie :)

Jeśli to co robisz żeby miało sens wymagałoby np. 20/10 zmian w kodzie, to jaki sens jest tego "live testingu"? Naprawdę cięzko wyobrazić sobie mi sensowny przypadek do tego

No nie wiem co Ci mam powiedzieć. Niektórzy widać to preferują, inni nie. Gdyby było inaczej, to MS nie chował by integracji z VS za ogromnym paywallem wersji Enterprise.

No skoro z tego korzystasz to może jesteś w stanie mnie oświecić. Ja praktycznie nigdy nie robię commitów gdzie zmieniam tylko jedną linijkę.

Przecież jest właśnie na odwrót- jeśli dokonujesz wielu zmian w kodzie, to często warto widzieć na bieżąco czy się czegoś nie zepsuło. Co jest alternatywą? Odpalanie testów manualnie albo czekanie na sam koniec.

Jeżeli robię wiele zmian, to wiem że w trakcie kod jest zepsuty i nie będzie działał. Po co mi odpalać testy które nie przejdzą i wiem dlaczego nie przejdą?

Po to że w pewnym momencie ten kod zadziała, a Ty... nie będziesz musiał robić nic. Bo wyniki testów będziesz miał zanim pomyślisz o ich odpaleniu.

Chodzi o zwykłą wygodę, nic więcej.

@Aventus: ale jako developer sam wiem kiedy ten kod powinien zadziałać. Nie klepię na palę czegokolwiek, tylko zazwyczaj w 100% jestem pewny co chcę napisać

sbt (build tool dla scali) ma automatyczne (po wykryciu zmian) odpalanie testów (albo dowolnego innego zadania) od dawien dawna (i to za darmo oczywiście): https://www.scala-sbt.org/1.x/docs/Triggered-Execution.html do testów tego nie używałem (z różnych względów, przede wszystkim dlatego, że w korpo wiele rzeczy jest przestarzałych, poblokowanych, bardzo długo się wczytuje, więc nawet nie chce się nikomu poprawie ustawiać etc), ale w warunkach domowych używałem tego triggered execution do automatycznej kompilacji i restartu serwera po edycji kodu i w ten sposób moja single-page-application odświeżała się automatycznie (tzn. zarówno backend jak i frontend). wystarczyło zrobić ctrl+s, przełączyć się na chrome'a, poczekać krótką chwilę i voila, widzimy odświeżoną apkę.

@scibi_92: Po co mi odpalać testy które nie przejdzą i wiem dlaczego nie przejdą w tej macierzy przejdą/nie przejdą x miałem rację, nie miałem najbardziej interesują cię przypadki, gdy nie masz racji. Drugie zastosowanie jakie widzę to odświeżane code coverage na bieżąco (nie wiem, czy ten ficzer tak ma) dzięki czemu w czasie pisania widzę zielony pasek mówiący, czy testy wchodzą do nowego kodu

@Aventus: Ale jak to niby działa ? W normalnych ide zawsze jest autozapis i nie wyobraz sobie pracy bez autozapisu. I co teraz co 300ms ci zabija testy które ew chodza i uruchamia je od początku ?

@Schadoow: W normalnych ide zawsze jest autozapis Trochę pojechałeś, nie róbmy z osobistych preferencji obiektywnej prawdy. Przede wszystkim to w wielu IDE domyślnie nie ma auto-zapisu, trzeba to włączyć. Notabene ja mam odmienne podejście- nie wyobrażam sobie pracy z auto-zapisem. Ale tak, jeśli masz auto zapis to chyba za każdym razem by Ci się uruchamiało w tle.

@Aventus: Czyli podsumowując masz manualny zapis ale automatyczne uruchamianie testów xD. Dla mnie to gwałt na logice i funkcjonalności.

I troche w takim razie nie rozumiem w czym ta funkcjonalnosc ci pomaga ? Czym to by różniło się od po prostu skrótu klawiaturowego ? Skoro i tak za każdym razem musisz wykonac manualną pracę aby zadział się efekt.

Dla mnie to gwałt na logice i funkcjonalności. No nieźle, to współczuję procesów logicznych. W sumie to nie mamy o czym dyskutować bo to kwestia preferencji. Równie dobrze możesz powiedzieć że jak ktoś woli Pepsi od Coli to gwałt na logice. Ja często robię zmiany w kilku plikach i dopiero zapisuję (skrótem klawiszowym). Nie rozumiem czego tu się na siłę doszukiwać- znam sporo osób które tak nie robią, i sporo (więcej) które tak robią. Kwestia preferencji. Co za pokręcony tok rozumowania, próbując przywoływać argument z logiką w takiej kwestii.

Czym to by różniło się od po prostu skrótu klawiaturowego ? Skoro i tak za każdym razem musisz wykonac manualną pracę aby zadział się efekt. A widziałeś w ile się wykonało 6 testów? 3ms. Różni się tym że zanim cokolwiek zrobisz, masz już wyniki testów.

@Aventus: czy masz jakieś "cięższe" testy, które np. odpalają kontenery? Jak to działa w takim podejściu?

@slsy: nie, mamy filozofię że developer pracujący nad kodem biznesowym powinien móc wszystko odpalić w IDE (lub CLI) bez żadnych dodatkowych zależności. Od cięższych testów mamy oddzielne repozytoria.

@Aventus: A widziałeś w ile się wykonało 6 testów? 3ms. Różni się tym że zanim cokolwiek zrobisz no właśnie nie zanim cokolwiek zrobisz. Triggerem w twoim przypadku jest wciśnięcie skrótu klawiszowego do zapisu. Ogólnie zaprzęgasz narzędzie do nasłuchiwania zmiana na filesystemie który to proces jest zasobożerny, żeby potem i tak wyjebać całą zalete bo musisz to triggerować i tak manualnie. Więc nie nie jest to kwestia preferencji tylko twoja kombinacja narzędzi jest bez sensu. Równie dobrze mógłby to być trigger w procesie zapisu w ide.

@Schadoow: triggerem jest zmiana w systemie plików, nic więcej. To jaki flow pracy ma @Aventus jest bez znaczenia. Takie testy odpalają się również jak jakiś zewnętrzny automat przemieli twój kod albo jak zrobisz git pull.

@slsy: A co ja napisałem ? narzędzie do nasłuchiwania zmian na filesystemie. Wiem jak to działa w moim ekosystemie w którym pracuje działa to grubo ponad 15 lat. Ale nie widziałem aby ktoś tego używał bo wygodniej jest triggerować testy skrótami.

Pogodzę Was - zarówno autozapis jak i automatyczne odpalanie testów to patologia i gwałt na logice. ;)