kto napisał 250 tys. testów dla webkitu?

Z wytycznych dotyczących wkładu do Webkit

„Dla każdej funkcji wpływającej na silnik układu należy skonstruować nowy test regresji. Jeśli dostarczysz łatkę naprawiającą błąd, łatka ta powinna również zawierać dodanie testu regresji, który nie powiedzie się bez łatki, a zakończy się powodzeniem z łatką Jeśli nie zostanie udostępniony test regresji, recenzent poprosi Cię o sprawdzenie poprawki, dzięki czemu możesz zaoszczędzić czas, konstruując test od początku i upewniając się, że jest on dołączony do błędu. Jeśli żaden test układu nie może (lub nie musi) zostać przeprowadzony skonstruowany na potrzeby poprawki, musisz wyjaśnić recenzentowi, dlaczego nowy test nie jest konieczny.”

P) Kto napisał te testy? A) Prawie wszyscy, którzy współtworzyli webkit.

Oryginalny katalog zawierał 240 tys. plików:

 Total Files Listed:
       243541 File(s)  1,062,470,729 bytes
       64718 Dir(s)

Wiele z nich to pliki svn. Jeśli usunę wszystkie podkatalogi o nazwie „.svn”, liczba plików spadnie do 90 KB:

 Total Files Listed:
       90615 File(s)    537,457,618 bytes
        7190 Dir(s) 

Niektóre katalogi mają podkatalog o nazwie „zasoby” i/lub „testy skryptów”. Myślę, że te podkatalogi zawierają pliki pomocnicze, które są używane przez przypadki testowe w nadkatalogach. Jeśli usunę te podkatalogi (ponieważ nie dodają się do całkowitej liczby testów), liczba plików spadnie do 87 KB:

 Total Files Listed:
       87672 File(s)    534,598,610 bytes
        6305 Dir(s)

Skondensowanie „podobnych” nazw plików (np. „klawisze-strzałek-na-body.html” i „klawisze-strzałek-na-body-expected.txt” to dwa pliki definiujące pojedynczy test) zmniejsza łączną liczbę z 87 tys. do 43 tys.

Jedynymi podkatalogami, które zawierają więcej niż 1500 takich przypadków testowych (liczonych jak opisano powyżej), są:

2761   LayoutTests\dom
10330  LayoutTests\fast (of which 5934 are in LayoutTests\fast\js)
22575  LayoutTests\platform (with various O/S-specific subdirectories).

Wydaje się, że w podkatalogach platform doszło do kopiowania i wklejania między platformami. Na przykład istnieje plik css3-modsel-37-expected.txt:

• W podkatalogu LayoutTests\platform\mac\css3
• W podkatalogu LayoutTests\platform\chromium-win\css3
• W podkatalogu LayoutTests\platform\qt\css3.

Jeśli odrzucę nazwy plików, które są zduplikowane w kilku podkatalogach platformy, wówczas będzie tylko 5716 (zamiast 22575) unikalnych testów platformy.

Podsumowując, myślę, że istnieje około 18 tys. unikalnych testów: co wciąż jest imponującą liczbą testów, ale mniej niż 250 tys., które oszacowałeś w swoim OP.

Dla porównania niedawno znalazłem zestaw testów CSS2.1: to wygląda na około 9000 przypadków testowych dla CSS.

Właśnie napisałem 4 testy jednostkowe w 5 minut. Nie wszystkie testy jednostkowe wymagają dużo czasu. Niektóre są bardzo proste ;)

• Istnieją takie rzeczy jak automatyczne generatory testów jednostkowych. W przypadku funkcji złożonej często może być konieczne wykonanie wszystkich permutacji możliwych wartości, powiedzmy, 7 parametrów. Jeśli są logiczne, otrzymasz 2⁷=128 testów. W niektórych scenariuszach wszystkie te 128 testów są generowane przy użyciu 10 wierszy kodu.

• Wiele testów jednostkowych opartych na regresji można wygenerować, pobierając duży zestaw danych wejściowych, uruchamiając na nich istniejący kod, rejestrując odpowiednie dane wyjściowe, a następnie wykonując testy gazillionowe, które pobierają nowy kod, uruchamiają go na tym samym wejściu i sprawdzają, czy dane wyjściowe pasują stare wyjście.

• Pisanie testów jednostkowych jest przedsięwzięciem dość rozproszonym. Równolegle mogą to robić armie stażystów/ochotników.

Nie wyglądają na testy jednostkowe: bardziej przypominają testy systemowe/regresyjne.

Nie jest to bezpośrednia odpowiedź na Twoje pytanie, ale opracowałem własną przeglądarkę, więc być może mam na ten temat pewien wgląd; Widzieć:

• Czy należy testować implementację wewnętrzną, czy tylko testować zachowanie publiczne?
• Testowanie

czy jakakolwiek mądra dusza na SO może rzucić trochę światła na to, jakiego rodzaju mityczni ludzie piszą nierealne ilości testów dla dużych projektów oprogramowania?

Napisanie tego rodzaju testu jest łatwe i konieczne:

• Łatwe: napisz stronę HTML (lub podobną czarną skrzynkę), aby sprawdzić funkcjonalność/funkcje/zachowanie
• Necessary:
  1. Need to test/exercise functionality when it's written
  2. Należy zademonstrować/odtworzyć błędy podczas składania raportu o błędach
  3. Należy zachować wszystkie poprzednie testy z punktów 1. i 2., aby przeprowadzić testy regresyjne

Mój szef powiedział kiedyś: „Dostajesz to, co sprawdzasz”. (co oznacza, że ​​wszystko, czego nie testujesz, jest nieznane/losowe).

To naprawdę zależy od tego, jak to zostało policzone.

Tak czy inaczej, gdy już zostanie skonfigurowany dobry framework do testowania konkretnej klasy/biblioteki/jednostki/cokolwiek, dodanie nowego testu zajmuje zwykle tylko kilka linii. Jeśli pisali testy, których celem był wysoki procent pokrycia kodu, testy te są zazwyczaj jeszcze krótsze, ponieważ wykonuje się wiele testów, które różnią się tylko wartością pojedynczej zmiennej, aby uzyskać inną ścieżkę kodu.

Twoja analiza jest w najlepszym razie niekompletna. Albo jest stronniczy, tak myślę.

Powinieneś policzyć liczbę testerów, niektórzy (lub wszyscy) z nich są w pełni oddani testowaniu i tylko testują, co zwiększa ich produktywność. Powinieneś także zdać sobie sprawę, że w wielu projektach bardzo niewiele testów jest skomplikowanych, a większość testów może być powtarzalna, dzięki czemu można je łatwo wdrożyć.

W komentarzach pytaliście:

kto obserwuje obserwatorów? ktoś musiał mieć koszmarną pracę wypasania tych wszystkich kaczątek

... I ...

prawda, zadajesz to samo pytanie co ja. ilu było testerów. kim oni są. czy są programistami czy pracownikami kontroli jakości? wolontariusze?

Być może odpowiedzi na Twoje pytania znajdziesz w Zasady osób zgłaszających i recenzentów WebKit.

zakładając wydajność 3 na godzinę, czyli 83000 godzin

Biorąc pod uwagę, że istnieje tylko 18 tys. unikalnych testów i 200 dni roboczych na osoborok, to jeśli przeznaczy się cały dzień na opracowanie każdego testu, wówczas zespół składający się z 9 pełnoetatowych testerów/osób ​​mógłby opracować 18 tys. testów w ciągu 10 lat ( Projekty KHTML i KJS KDE rozpoczęły się w 1998 roku). Liczby te prawdopodobnie są nieistotne (opracowanie każdego nowego przypadku testowego może nie zająć jednego dnia i mogą nie mieć pełnoetatowych/dedykowanych testerów), ale IMO pokazują, że 18 tys. testów w ciągu 10 lat jest wykonalne dla „dużej” ( lub nietrywialny), udany projekt.

W moim projekcie stosuję podobną strategię testowania: nie dlatego, że skopiowałem Webkit, ale dlatego, że jest to jedyny sposób, jaki przychodzi mi na myśl, aby wykonać zautomatyzowane, ale łatwe w utrzymaniu testy regresyjne GUI.

Poniższy FYI jest przykładem (jednym z najkrótszych/najprostszych przykładów) jednego z moich przypadków testowych. Generuję go (i inne podobne) po prostu ręcznie uruchamiając interfejs mojej przeglądarki w ramach wbudowanego środowiska generowania przypadków testowych. Następnie mogę uruchomić ponownie później jako zautomatyzowany test regresji (struktura odtwarza dane wejściowe i potwierdza, że ​​dane wyjściowe się nie zmieniły).

Uważam, że tworzenie przypadków testowych nie jest czymś, co zajmuje stosunkowo dużo czasu.

> clientSize 20 10
+ screenDisplays lines 0
----------
----------
> loadDocument lines 5
----------
<div>
<h1>Easy title</h1>
<p>Hello world. Lorem ipsum.</p>
<p>Embedded <a>anchor</a> tag.</p>
</div>
----------
< invalidateAll
> paint 0 0 20 10
+ screenDisplays lines 10
----------
····················
····················
··»«Easy title········
····················
····················
··Hello world. ·····
··Lorem ipsum.······
····················
····················
··Embedded anchor ··
----------
> mouse down 9 2
< ensureVisible 9 2 1 13
+ screenDisplays lines 10
----------
····················
····················
··Easy ti»«tle········
····················
····················
··Hello world. ·····
··Lorem ipsum.······
····················
····················
··Embedded anchor ··
----------
> mouse up 9 2
< ensureVisible 9 2 1 13
+ screenDisplays lines 10
----------
····················
····················
··Easy ti»«tle········
····················
····················
··Hello world. ·····
··Lorem ipsum.······
····················
····················
··Embedded anchor ··
----------
> keyDown Enter
< invalidate 2 2 16 1
< invalidateAll
< invalidate 2 4 16 3
< ensureVisible 2 5 1 16
+ currentDocument lines 6
----------
<div id="ModelText_id_contents">
 <h1>Easy ti</h1>
 <h1>tle</h1>
 <p>Hello world. Lorem ipsum.</p>
 <p>Embedded <a>anchor</a> tag.</p>
</div>
----------
+ debugDumpDom lines 15
----------
 1  div
 2    h1
 3      Easy ti
 4    h1
 5      tle
 6    p
 7      Hello world. Lorem ipsum.
 8    p
 9      Embedded 
10      a
11        anchor
12       tag.

Selected start={parentId=4,parent={tle},offset=0}, end={parentId=4,parent={tle},offset=0}

----------
> paint 0 0 20 10
+ screenDisplays lines 10
----------
····················
····················
··Easy ti···········
····················
····················
··»«tle···············
····················
····················
··Hello world. ·····
··Lorem ipsum.······
----------