Firmy gdzie stosuje się TDD.

0

Cześć,

Jest wiele ogłoszeń, gdzie firmy szukają kandydatów z umiejętnością tworzenia kodu w metodologii TDD.
Ale jak się później okazuje nikt w firmie nawet nie "stoi" przy takim podejściu. Wszyscy piszą wpierw kod, później testy.

Znacie może jakieś dobre firmy gdzie NAPRAWDĘ stosuje się podejście TDD przy tworzeniu kodu.

6

Zamiast szukać firmy, najlepiej wprowadzić od dzisiaj do swojego projektu samemu. Jak będzie działać, to ludzie sami pójdą za Twoim przykładem.

1

Bo to jest strata czasu tak naprawdę

1
Biały Lew napisał(a):

Bo to jest strata czasu tak naprawdę

ja mam takie zajebiscie ale to zajebiscie wazne i trudne pytanie

Skoro
testy sa takie zaejebiste, to
dlaczego
przed napisaniem testów poprzedzajacych kod,
nie pisze się testów testujących te testy?

Przecież oszczędność czasu itd. w pozniejszej perspektywie itd...

2

W sumie, dobre pytanie. Przecież testy nieraz poziomem skomplikowanie i zagmatwania nieraz przerastają kod, który mają testować. Poza tym, kod potrafi napisać każdy i przeważnie nawet ten kod działa i jest zrozumiały dla innych.

Natomiast, testy to mało kto umie napisać, więc jest to trudniejsze niż napisanie kodu. Warto by więc pisać testy testujące inne testy, tak aby upewnić się, że testy są dobre. Takie podwójne TDD

3

Nikt nikomu nie broni pisać dodatkowego zestawu testów do skomplikowanej infrastruktury testowej. Potrzeba jednak jest raczej rzadka.

Pisanie testów do testów w ogólności jest jednak absurdem. Test automatyczny jest niczym innym jak alternatywą dla testu manualnego. Zysk z testu automatycznego jest taki, że wykonuje go komputer, a nie człowiek. Czas komputera jest znacznie tańszy niż czas człowieka i z tego wynika zysk z testów automatycznych. Testy automatyczne do testów automatycznych mają natomiast mniej więcej taki sam sens jak testy manualne do testów manualnych.

W naszym projekcie nie ma testerów wykonujących te same testy manualnie w kółko. Testy manualne są wykonywane tylko po to, by sprawdzić czy nowe funkcjonalności działają tak jak je sobie biznes wymyślił. Może się zdarzyć tak, że programiści źle zrozumieją wymagania i zakodują coś sprzecznego z wizją biznesu, więc testować trzeba. Jednak jeśli biznes zaopiniuje nową funkcjonalność pozytywnie to nie ma sensu testować jej ręcznie ponownie.

Nasz projekt ma kilka lat i biorąc pod uwagę numerki buildów w systemie ciągłej integracji to przeciętny test automatyczny był wykonywany ponad dziesięć tysięcy razy.

Jeżeli wasz projekt nie jest regularnie i dogłębnie testowany to prawdopodobnie nie jest to system o dużym znaczeniu. W poważnych systemach błędy są kosztowniejsze niż testy które mają przed nimi uchronić.

0

Skoro
testy sa takie zaejebiste, to
dlaczego
przed napisaniem testów poprzedzajacych kod,
nie pisze się testów testujących te testy?

Też mnie to zastanawiało zawsze. Ale z drugiej strony testy zwykle są bardziej straightforward niż produkcyjny kod

  • Mniej abstrakcji (a jeśli jest jakaś zaawansowana abstrakcja w testach to moim zdaniem powinna być przetestowana jednak, tak jak same frameworki do testów też ktoś testuje przecież).
  • zahardkodowane wartości (np. assert(foo === 42) w normalnym kodzie trzeba by wydzielić gdzieś stałą, a w testach magiczne liczby są okej
  • copy paste też bywa okej (ponieważ sprzyja temu, że kod jest bardziej explicit)
  • przypadki testowe są nudne i polegają na tym samym głównie, na wywołaniu jakichś funkcji i sprawdzeniu wyniku. Nie ma tu ifów, czy innych skomplikowanych struktur kontrolnych.

(a to wszystko sprawia, że można łatwiej wyłapać samemu błędy w jakimś prostym unit teście, niż w kodzie produkcyjnym z milionem abstrakcji rozsianym po wielu plikach i ze skomplikowaną logiką, i zależnościami do milionów różnych funkcji)

Co prawda co najmniej parę razy (a pewnie i więcej) zdarzyło mi się napisać zły test, tj. test, który nie testował tego, co trzeba. Tylko pytanie - jak to przetestować? Zwykle problem nie polega na tym, że testy źle działają, tylko na tym, że nie testują tego co trzeba (np. mają asercje nie do tego, co trzeba). Czyli człowiek próbując wyobrazić sobie działanie programu, źle go sobie wyobraził i testował nie to, co trzeba.

Tego raczej i tak nie dałoby się przetestować automatycznie (chyba, żeby ktoś zrobił sztuczną inteligencję do testowania tego, czy użyte asercje mają sens - ale jeśli by ktoś tego dokonał, to w ogóle już testy jednostkowe mogłyby pisać się same).

0

luxmed?

2
LukeJL napisał(a):

Skoro
testy sa takie zaejebiste, to
dlaczego
przed napisaniem testów poprzedzajacych kod,
nie pisze się testów testujących te testy?

Też mnie to zastanawiało zawsze. Ale z drugiej strony testy zwykle są bardziej straightforward niż produkcyjny kod

Testy testów to kod, TDD to relacja dwustronna. Jak masz skopane testy to kod, który próbujesz napisać, to wykaże. No a jedno z tych dwóch musi być piersze bo fizycznie się inaczej nie da ;)

  • zahardkodowane wartości (np. assert(foo === 42) w normalnym kodzie trzeba by wydzielić gdzieś stałą, a w testach magiczne liczby są okej

Tu się nie zgodzę, ja mam właczone no-magic-numbers dla całości projektu. O ile przytoczona asercja nie boli, to w wielu innych przypadkach psuje to czytelność jak w normalnym kodzie (a konsekwentne napisanie expected = 42 tez nie jest jakieś straszne).

  • copy paste też bywa okej (ponieważ sprzyja temu, że kod jest bardziej explicit)

True, choć powtarzalny setup testu należy wydzielić - byle nie ukrywać asercji.

1

To może testy do testów do testów do testów?

0

A dlaczego testy i kod do testów pisze jedna i ta sama osoba?

4
Maciej Cąderek napisał(a):

Też mnie to zastanawiało zawsze. Ale z drugiej strony testy zwykle są bardziej straightforward niż produkcyjny kod

Testy testów to kod, TDD to relacja dwustronna. Jak masz skopane testy to kod, który próbujesz napisać, to wykaże. No a jedno z tych dwóch musi być piersze bo fizycznie się inaczej nie da ;)

Testy testów jak najbardziej się robi:
https://pl.wikipedia.org/wiki/Testowanie_mutacyjne

0

Czyli wychodzi, że testy stosowane są "gdzie nie gdzie", a o samym TDD to większość nie ma zielonego pojęcia bo TDD != UnitTests.
Na pytanie zadane w temacie to w sumie nikt nie odpowiedział albo potwierdza się założenie, że nie ma firmy, która stosuje TDD.

2

@loza_szydercow @LukeJL

Odpowiadam w poscie, bo miejsca potrzebuję

"Testy testów to kod, TDD to relacja dwustronna. Jak masz skopane testy to kod, który próbujesz napisać, to wykaże" - ja widziałem skopane testy które nigdy nie failowały tylko dlatego że ktoś zmienił charakter testowanego kodu na asynchroniczny i skoro nie miał faila to uznał że test jest ok. Ciekawe ile takich false positive testów siedzi w dużych projektach.

Zmiana kodu na asynchroniczny to nie jest nieinwazyjny refaktor, więc (zgodnie z TDD) zanim się taką zmianę wykona należy zmienić powiązane z tym kodem testy, tj. zmodyfikować je tak by obsłużyły nową wersję i co za tym idzie zfailowały. Wtedy nie masz sytuacji, że testy źle napisane i przechodzą.

Zdarzyło mi się na CR widzieć np takie kwiatki (uwaga JS, ale prosty):

// function returns asynchronous result:
import someFunction from './some-function'

describe('some test suite', () => {
  it('some test case with asynchronous behaviour', () => {
    const input = 11
    const actual = someFunction(input)
    const expected = 121

    expect(actual).to.eventually.equal(expected)
  })
})

Test przechodzi, na pierwszy rzut (nieprzyzwyczajonego) oka nie widać błędu. W czym problem? Brakuje return przed expect, mocha wymaga returna jak testujesz promisy. Niby słabe, bo przez zwykłą nieuwagę (lub nieznajomość działania frameworka testującego) mamy wiecznozielone testy.
Ale!
Od razu widać, że testy zostały napisane po napisaniu kodu ;)

Ponownie, gdyby proces pisania kodu wyglądał następująco:

  1. piszemy testy i tylko tyle kodu by się skompilowało (czyli zazwyczaj puste funkcje jeśli chodzi o JS) ale żaden z testów nie przeszedł
  2. piszemy kod tak aby failujące do tej pory testy przeszły.

to ten pozornie trudny w wyłapaniu błąd jest wyłapany już na pierwszym etapie.

0

Na pytanie zadane w temacie to w sumie nikt nie odpowiedział albo potwierdza się założenie, że nie ma firmy, która stosuje TDD.

Poszukałbym bardziej w firmach, które zajmują się Ruby czy JSem, albo innym dynamicznym językiem. Tam mi się wydaje TDD jest najmodniejsze.

0

To nie firmy stosują TDD - to ludzie. I niekoniecznie zawsze , niekoniecznie we wszyskich projektach.
Ja częściej stosuje - zależy to od projektu - zwykle jak wskakuje na dłużej w większą kobyłe to musze troche poustawiać infrastrukturę, żeby TDD (sensownie) sie w ogóle dało stosować :/ . Dlatego jak wpadam na chwile, a projekt to martwica mózgu to czasem olewam TDD i testy całkiem :-).

Właśnie mam śmieszny podprojekt - kolega robi kod (bo siedzi w projekcie od 2 lat, a jest raczej skomplikowany algorytm do napisania).
Ja się uczę projektu pisząc niezależnie testy do tej funkcjonalności.
Na razie to wygląda tak:
fail

Ale tak naprawde to już ileś kasztanów koncepcyjnych w ten sposób znaleźlismy. (czyli w pewnym sensie fail pozytywny).

0
Nadziany Kret napisał(a):

Czyli wychodzi, że testy stosowane są "gdzie nie gdzie", a o samym TDD to większość nie ma zielonego pojęcia bo TDD != UnitTests.
Na pytanie zadane w temacie to w sumie nikt nie odpowiedział albo potwierdza się założenie, że nie ma firmy, która stosuje TDD.

Bo to pytanie nie ma sensu. Co to znaczy "firma stosuje"? Czy aby tak powiedzieć wystarczy aby jedna osoba chociaż raz użyła tego podejścia? Czy może wszyscy zawsze w każdym przypadku?
Bo moim zdaniem, to decyzja o tym, czy w danym przypadku użyć TDD czy nie, powinna być indywidualną decyzją programisty, a nie jakimś nakazem czy zakazem.
TDD to nie jest rozwiązanie wszystkich problemów i jest sens je stosować jedynie w określonych sytuacjach.

0
Wibowit napisał(a):

Nasz projekt ma kilka lat i biorąc pod uwagę numerki buildów w systemie ciągłej integracji to przeciętny test automatyczny był wykonywany ponad dziesięć tysięcy razy.

Wspomniałeś bardzo ważną rzecz- system ciągłej integracji. Właśnie dzięki testom automatycznym możemy robić automatyczne wdrożenia z dużą pewnością siebie i małym ryzykiem, że położymy system produkcyjny (a jak wiadomo, położenie ważnego systemu produkcyjnego bardzo często wiąże się z ogromnymi stratami dla biznesu).

Mam wrażenie, że nie wiele osób to ogarnia...

1 użytkowników online, w tym zalogowanych: 0, gości: 1