Jestem zainteresowany następującym scenariuszem. Załóżmy, że masz zespół, który pisze kod produkcyjny i zespół, który pisze automatyczne testy. Zespół, który pisze testy automatyczne, ma dedykowane ramy przeznaczone do pisania testów automatycznych. Czy zespół testujący powinien napisać testy jednostkowe dla swojej frameworki, mimo że ramy nie są wykorzystywane w produkcji?Czy przeprowadzasz testy jednostkowe dla kodu nieprodukcyjnego?
byłem w takiej sytuacji i to, co zrobiłem, to użyć zestawu testowego kodu produkcyjnego również jako zestaw testowy do testowania ramy . Przypuszczalnie wszystkie funkcje szkieletu zostały faktycznie użyte, więc jeśli testy nie powiodły się bez zmiany kodu produkcyjnego, musi to być problem w strukturze testowania.
Udało się OK-ish - uruchomienie tych testów zajęło znacznie więcej czasu niż posiadanie dedykowanego testu-testu, a czasami nie uruchomiłbym ich wszystkich i nie pojawiłbym się na serwerze budowania produkcji. Diagnozowanie takich problemów trwało znacznie dłużej niż w przypadku testu-testu.
Podsumowując, nigdy nie czułem się z tym komfortowo i naprawdę poleciłbym mieć dedykowane testy dla szkieletu testowego. Z punktu widzenia zespołu testującego, framework testowy to kod produkcyjny. A jeśli ramy testowe kiedykolwiek zostaną wykorzystane przez kogoś innego, którego zestawy testów nie masz dostępu do ...
Tak, jeśli tylko w celu sprawdzenia, czy struktura generuje wystarczający zasięg testu.
Hell yes!
TDD daje przewagę w rozwoju, nie jest po prostu zadowolić klienta. Pozwala pisać testowalny, wielokrotnego użytku i modułowy kod. Chciałbym przetestować wszystko, co musi zadziałać, szczególnie jeśli spodziewasz się często go zmieniać (refaktor dodawać nowe funkcje).
Zespół testujący powinien zrobić wszystko, co może zwiększyć zaufanie do wyników dostarczanych przez ich framework.
ta obejmuje testowanie, recenzje Kodeksu standardów jakości, ...
To pytanie przypomina mi pewną historię: Dawno, dawno temu istniała firma. Ta firma wierzy w automatyczne testy. To przekonanie jest tak silne, że prowadzi do stworzenia grupy, której jedynym celem jest pisanie tych automatycznych testów. Wszyscy najgorętsi wierzący mogą dołączyć do tej grupy. Było dużo radości!
Pewnego dnia odkryto, że ta automatyczna grupa testowa pomimo swojej misji nie używa automatycznych testów do własnej pracy. Kamienie są rzucane, Yada Yada.
Po prostu mówię ... Myślę, że wszelkie ramy testowe miałyby całkiem solidny zasięg testów.
Możesz spojrzeć na moje pytanie w ten sposób. Ale myślę, że naiwnością jest decydowanie o testowaniu kodu nieprodukcyjnego na podstawie tego argumentu. Utrzymanie testów kosztuje na końcu i osobiście uważam, że powinieneś przetestować tylko strukturę automatyzacji, a nie każdą część laboratorium automatyzacji. Z drugiej strony, w kodzie produkcyjnym twoim celem jest przetestowanie jak najwięcej. To jest powód mojego pytania. – Ikaso
Przerzucam, ale moim celem jest zastosowanie tych samych kryteriów oceny. Dlaczego piszemy testy automatyczne, nawet jeśli dodadzą 15% do kosztów opracowania? Ostatecznie odpowiedź brzmi: ponieważ zwiększa naszą pewność co do kodu_. To nie jest czarno-białe - pytanie brzmi, czy powinniśmy napisać jeszcze jeden test?Jeśli mamy już zaufanie do kodu lub zaufanie nie jest takie ważne, nie trzeba pisać testu. Zastosowałbym tę wytyczną, czy konsument oprogramowania jest klientem komercyjnym, deweloperem, czy moim młodszym bratem. – ndp