Czy ktoś użył Testowania Jednostki jako sposobu uczenia się programowania?

Question

Rozumiem koncepcję testowania jednostek jako wymyślanie prostych pomysłów na temat tego, co powinien wygenerować twój kod - a następnie wyprowadzenie go. Zastanawiasz się więc, co chcesz zrobić, aby zrobić kod - następnie wykonaj test, aby upewnić się, że działa.

W którym momencie programowania uczenia się należy uwzględnić TDD (testowanie jednostkowe)?

Edytuj: Spodobał mi się komentarz dotyczący testów jednostkowych, gdy tylko narzędzia do tego przestaną być magiczne.

Pierwotnie powstało pytanie, ponieważ zdałem sobie sprawę, że nie mam jeszcze umiejętności opracowania dużego programu, ale chciałbym się dowiedzieć, wymyślając pomysły na to, co może/powinien zrobić jakiś fragment kodu.

Chciałbym dostać się do nauki przez działanie i myślę, że zorganizowany sposób na to pomoże. Python jest językiem, którego używam. Dziękuję za dotychczasowe wejście.

Answer 1

Testowanie jednostkowe to ogromna oszczędność czasu, gdy zaczynasz, ponieważ kończy się wykonywanie wielu "kodu, uruchomienia, debugowania" cykle podczas nauki. To "run" fazy, która staje się ssać czas, gdy robisz to ad-hoc za każdym razem. Myślę też, że początkujący mają tendencję do wprowadzania więcej problemów z regresem, co jest kolejnym ogromnym czasem, jeśli nie od razu je łapiesz testem jednostkowym.

Answer 2

Jak najwcześniej. Wszystkie moje przeszkody w przyjęciu TDD były spowodowane tym, że musiałem przełamać stare nawyki i zmienić sposób myślenia. Gdybym mógł od początku myśleć o terminach TDD, znalazłbym to wszystko znacznie łatwiej.

Answer 3

Czy mówimy o całkowitym początkującym lub programistą, który uczy się nowego języka? Jeśli to drugie - powiedziałbym od razu. Dlaczego? Ponieważ najlepszym sposobem nauki jest kodowanie, a kodowanie należy przetestować. Jednak ktoś, kto nie ma pojęcia programowania, prawdopodobnie powinien nauczyć się podstaw programowania

Answer 4

TDD sprawia, że ​​myślisz o wiele więcej przed kodowaniem - coś, czego brakowało mi na początku mojej kariery. Kiedyś wstałem i działałem w IDE i zacząłem pisać - kod i poprawka, jak mówią.

Gdybym użył jednostki badań i TDD wcześniej w moim rozwoju jako programista, następnie mocno wierzę mogłem przyniosły lepszą jakość kodu szybciej (nie, że mój kod w tym czasie był całkowity umysł bzdura :)

Answer 5

Oczywiście jest to bardzo subiektywne pytanie, ale myślę, że możemy nałożyć na to wczesny limit. Powiedziałbym, że nie wcześniej, niż operacje w ramach testów jednostkowych przestaną wyglądać jak magia. Zatem w Javie, z JUnit, musisz najpierw zrozumieć Wyjątki, metody, wartości zwracane, parametry, podstawowe operatory, takie rzeczy.

Częścią problemu jest to, że wiele prostych przykładów programowania wymaga wprowadzenia danych przez użytkownika, co jest trudne do sprawdzenia w jednostce, więc nie chcesz zbyt wcześnie na to przeszkodzić, ale jeśli testowanie jednostkowe było często wykonywane wcześniej, może to ułatwić test kodu jednostkowego, który musi to zrobić.

Answer 6

myślę paradygmat (zmiana w myśleniu) potrzebne do pracy z TDD (lub chcą do pracy z TDD) jest to, że justfied przez „holistycznego” Widok gdzie programiści spędzają czas i wartość dodaną. Czyści zwinni primerzy są wyszkoleni, aby przekonać się, że fragment kodu ma wartość dodatnią (i jest liczony jako "zrobiony") tylko wtedy, gdy prawidłowo osiąga swój cel (przekształcenia czegoś itp.). Dzieje się tak dlatego, że oszukujemy samych siebie tylko pod względem wartości (akceptowalności), chyba że jest to poprawne.

Definiowanie konstrukcji testowej najpierw definiuje cel kodowania i miejsce, w którym może wystąpić błąd (skrajne testy testowe na krawędzi). Ponadto sprawdzanie, czy cel został osiągnięty, jest zautomatyzowane.

Answer 7

Testowanie w ogólności powinno być prowadzone jako część pierwszego kursu programowania, IMO. Testowanie jednostek niekoniecznie jest czymś, co postawiłem na początku, ponieważ idea tego, co jest lub nie jest "jednostką", może z łatwością stać się tematem semantyki i filozofii. Określanie typów testów jako testów jednostkowych, które mogłem zobaczyć na drugim lub trzecim kursie. Oczywiście nie pamiętam uczenia się testów jednostkowych na uniwersytecie, więc jakoś nie dostałem się do programu nauczania, do którego chodziłem do szkoły w latach 90.

TDD jako filozofia może być prawdopodobnie wykorzystana wkrótce po uzyskaniu podstawowych pomysłów na testowanie. Nie jestem pewien, czy chciałbym przejść przez wszystkie rodzaje testów z ludźmi, którzy nie mają pojęcia, jaki kod wygląda. Gdy ktoś uzyska kilka podstaw programowania, testy staną się użytecznym sposobem pokazania, że ​​"Tak, ten program robi to, co trzeba". Studenci wypróbowujący TDD mogą postrzegać to jako coś łatwego i naturalnego, jeśli wciąż są względnie nowi w programowaniu, podczas gdy ci, którzy programowali przez lata, mogą mieć trudności z dostosowaniem się do paradygmatu.

Answer 8

Jako zdawkowe, TDD i/lub testy jednostkowe mogą przyjść bardzo późno w procesie uczenia się . Nawet doświadczeni programiści mogą zacząć od testów szkoleniowych podczas rozpoczynania pracy z nowym językiem lub nowym interfejsem API.

Kent Beck rekomenduje to pod nazwą "Learning test" w swoich wzorach "Czerwony pasek " w opracowaniu opartym na testach: według przykładu.

Zamiast po prostu przy użyciu nowej metody lub nowej klasy, możemy napisać mały test który weryfikuje, że API działa zgodnie z oczekiwaniami.

Podobnie Mike Clark napisał pakiet ponad 400 testów podczas learning Ruby.

Pisanie testów nauki jest zabawnym sposobem na przesłuchanie i prod każdego nowego języka lub interfejsu API. I przy każdym teście, który piszesz, jesteś inwestujesz w bazę wykonawczą o nazwie .

Answer 9

Chyba twoja koncepcja testów jednostkowych nie jest poprawna. Technicznie rzecz biorąc, "testowanie jednostkowe" to metoda weryfikacji i walidacji oprogramowania, w której programista sprawdza, czy poszczególne jednostki kodu źródłowego są odpowiednie do użycia. Jednostka jest najmniejszą testowalną częścią aplikacji. W programowaniu proceduralnym jednostka może być indywidualną funkcją lub procedurą, aw Programowaniu obiektowym może to być metoda klasy.

To, co chcesz zrobić, to w zasadzie "robienie mniejszych programów w pierwszej kolejności, a następnie stopniowe ich komplikowanie (i oczywiście podczas nauki programowania)". Ten typ tworzenia oprogramowania "zaczyna się od prostszych, a następnie stopniowo go komplikuje" jest technicznie nazywany "prototypowaniem oprogramowania". Oto jego definicja:

"Prototypowanie oprogramowania, działanie podczas pewnego rozwoju oprogramowania, polega na tworzeniu prototypów, tj. Niepełnych wersji opracowywanego oprogramowania. Prototyp zazwyczaj symuluje tylko kilka aspektów funkcji końcowego programu i może być zupełnie inny niż ewentualna implementacja. Konwencjonalnym celem prototypu jest umożliwienie użytkownikom oprogramowania ocenienie propozycji programistów dotyczących projektu końcowego produktu poprzez rzeczywiste wypróbowanie ich, zamiast interpretowania i oceny projektu na podstawie opisów. Prototypowanie może być również wykorzystywane przez użytkowników końcowych do opisywania i potwierdzania wymagań, których deweloperzy nie uwzględnili, więc "kontrolowanie prototypu" może być kluczowym czynnikiem w relacjach handlowych między dostawcami rozwiązań a ich klientami. "

Z drugiej strony hand, Unit Testing to tylko jedna z metodologii "Testowania Oprogramowania", która nie jest częścią początku rozwoju oprogramowania, jest wykonywana na końcu, gdy został utworzony dość duży program i dla zapewnienia każdej części (tj. takie jak funkcje, procedury, metody klasowe itp.) działają poprawnie, testowanie jednostek nie może być wykorzystywane do oparcia rozwoju oprogramowania, ponieważ na końcu, jeśli wyniki testów jednostkowych na "dowolny element ma błąd", oznacza to, że całe oprogramowanie jest błędne, podczas gdy jeśli Testowanie jednostek mówi "wszystkie kawałki nie zawierają błędów, to nie znaczy, że całe oprogramowanie jest błędne e "ponieważ mogą wystąpić pewne błędy w integracji tych elementów lub nie można oczekiwać, że testowanie jednostek wykryje każdy błąd w programie: niemożliwe jest oszacowanie każdej ścieżki wykonania we wszystkich, oprócz najbardziej trywialnych programach. To samo dotyczy testów jednostkowych. Dodatkowo testowanie jednostkowe z definicji sprawdza jedynie funkcjonalność samych jednostek. W związku z tym nie będzie wychwytywał błędów integracji lub szerszych błędów na poziomie systemu (takich jak funkcje wykonywane w wielu jednostkach lub niefunkcjonalne obszary testowe, takie jak wydajność). Testowanie jednostkowe musi odbywać się w połączeniu z innymi czynnościami testowania oprogramowania. Podobnie jak wszystkie formy testowania oprogramowania, testy jednostkowe mogą jedynie wykazać obecność błędów; nie mogą pokazać braku błędów.

Aby uzyskać zamierzone korzyści z testów jednostkowych, w całym procesie tworzenia oprogramowania wymagana jest rygorystyczna dyscyplina. Konieczne jest zachowanie dokładnych zapisów nie tylko wykonanych testów, ale także wszelkich zmian, które zostały wprowadzone w kodzie źródłowym tego lub jakiegokolwiek innego urządzenia w oprogramowaniu. Konieczne jest zastosowanie systemu kontroli wersji. Jeśli późniejsza wersja urządzenia nie przejdzie pomyślnie przez test, który wcześniej przeszedł, oprogramowanie kontroli wersji może dostarczyć listę zmian kodu źródłowego (jeśli istnieją), które zostały zastosowane do urządzenia od tego czasu.

Niezbędne jest również wdrożenie zrównoważonego procesu zapewniającego codzienne sprawdzanie niepowodzeń przypadków testowych i natychmiastowe ich rozwiązywanie. Jeśli taki proces nie zostanie wdrożony i nie zostanie uwzględniony w obiegu pracy zespołu, aplikacja będzie ewoluować niezsynchronizowana z zestawem testów jednostkowych, zwiększając liczbę fałszywych alarmów i zmniejszając skuteczność zestawu testów.

Mam nadzieję, że teraz lepiej rozumiesz termin "testowanie jednostek". A czego chcesz się nauczyć przez "prototypowanie oprogramowania". Cóż, jeśli chodzi o uczenie się, możesz wybrać dowolny sposób, np. a) Przed rozpoczęciem kodowania przeczytaj wiele programów. b) Po prostu przeczytaj kilka podstawowych tematów dowolnego języka programowania i zacznij tworzyć prostsze programy, a następnie spraw, aby były bardziej złożone i zawierały większą wiedzę.

Wariant (a) zajmuje mniej czasu, aby dostać się na drodze biegłego, a także nie jest mniejsza szansa na przyjęcie niewłaściwych praktyk, które mogą wystąpić podczas „programowania samokształcenia”

Option (b) zajmuje więcej czasu abyś był na drodze eksperta, ale być może wymyślisz własny styl programowania i może stać się tak dobry, jak (jeśli nie lepszy) styl programowania innego eksperta.

POLECAM, NIE WYBIERAJ TYLKO JEDEN SPOSÓB powyżej wymienionych opcji (a) lub (b). WYKORZYSTAJ MIESZANKĘ OBU I ROZPOCZNIJ Z OPCJĄ (a).

Happy Programming!Witamy w Crazy Community!

Answer 10

Wydaje mi się, że przeprowadzanie testów jednostkowych dotyczy raczej uczenia się dobrych praktyk projektowych niż programowania w ogóle. Stwierdziłem, że podczas pisania testów jednostkowych jednocześnie projektuje się lepsze komponenty z czystszymi interfejsami między nimi.

Answer 11

Zwłaszcza biorąc pod uwagę kontekst - testy jednostek Pythona są bardzo łatwe do napisania i wymagają bardzo mało zrozumienia - powiedziałbym, że idę na to i zasymuluję twoje zrozumienie i eksploracje za pomocą testów.

Po wykonaniu tej czynności przez jakiś czas dołącz do etapu recenzji, gdzie powrócisz i przeczytasz wcześniejsze testy i zobaczysz, jak byś przepisał je zgodnie z aktualnym stanem wiedzy. Po to są komentarze - pisz pytania i przeglądaj notatki do siebie w instrukcjach wewnątrz każdej definicji testu.

Przy tak inkrementalnym podejściu, używanie kontroli wersji pomoże w recenzowaniu i bardzo ją polecam, w szczególności, ponieważ będziesz mógł zobaczyć historię zmian z logów kontroli wersji, a tym samym więcej samo-zachęty z widoczny postęp. Polecam git i używając wbudowanego gitgui lub GitX na Macinosh.

Jako bardzo doświadczony profesjonalista poprzednio testowałem jednostkę testując koncepcję, ale z pewnością użyłem wielu małych testów, aby nauczyć się nowych bibliotek i języków.

Answer 12

Moim zdaniem to ogromne i potężne narzędzie do nauki. Używam do nauki javascript i python i miałem doskonałe wyniki.

Nie mówię o badaniu jednostkowym, mówię o używaniu babysteps, czerwonego zielonego refaktora ... tych wszystkich praktyk, które zmieniają proces uczenia w łatwy proces.

Więc staram się zaczynać od małych kawałków, robić manekiny i zwiększać trudność przy użyciu twardych kawałków języka.

Potem zauważam, że kończę pisanie znakomitego źródła badań tylnych, więc jeśli mam jakiekolwiek wątpliwości, wracam do mojego tddlearn i rozwiązam go, lub gdy znajdę lepszy sposób na zrobienie czegoś lub znalezienie ograniczenia , Piszę testy na to ...

to niesamowite!

można oglądać moje postępy here

Answer 13

nie mogę uwierzyć, że nikt nie wspomniał kata:

https://github.com/gamontalvo/awesome-katas

a podobne koanami:

https://github.com/ts25504/awesome-koans

Zarówno koncepcja uczą poprzez samouczenie się poprzez pisanie i wykonywanie testów, dopóki nie przejdą.

Podejście "od góry do dołu" TDD bardzo przypomina podstawowe podejście akademickie; gdzie temat jest wprowadzany jako pierwszy, często jako domniemanie, a następnie przewiercony do konkretnych szczegółów.