Czy dobrym pomysłem jest TDD na komponentach niskiego poziomu?

Zastanawiam się nad napisaniem sterownika niskiego poziomu lub komponentów / jądra systemu operacyjnego.

Ludzie z osdev.org wydają się myśleć, że ważne fragmenty nie są w znaczący sposób testowane w ten sposób, ale przeczytałem kilka dyskusji, w których ludzie myśleli inaczej. Rozejrzałem się, ale nie znalazłem prawdziwych przykładów TDD na komponentach niskiego poziomu.

Czy to jest coś, co ludzie robią, czy tylko coś, o czym ludzie mówią w teorii, ponieważ nie ma dobrego sposobu na zrobienie tego w praktyce?

— Rachunek
źródło

Gdyby tylko MS dostarczyło programistom jądra odpowiednie „makiety jądra” (lub cokolwiek by to nie było), myślę, że omawiana praktyka nie byłaby tak „pomysłowa”.

— mlvljr

Cześć @Bill - Przeredagowałem trochę twoje pytanie i głosowałem za jego ponownym otwarciem. Jeśli zmieniłem to za bardzo z twojego pierwotnego zamiaru, możesz edytować dalej lub cofnąć pytanie :)

— Rachel

Z mojego punktu widzenia mówi to samo - bez obaw

— Bill

Odpowiedzi:

Jeśli wchodzisz w interakcję lub kontrolujesz sprzęt, trudno go przetestować bez niego. Możesz spróbować emulować sprzęt, ale często jest to trudniejsze niż napisanie sterownika, więc nie wiesz, czy błąd jest w twoim sterowniku, czy emulatorze.

— TMN
źródło

Dlaczego więc nie przetestować emulatora? ;)

— mlvljr

@mlvljr: ponieważ emulatory nie są prawdziwe. nie da się zastąpić prawdziwego sprzętu.

— Paul Nathan

@mlvljr Trzeba też przetestować emulator na prawdziwym sprzęcie, używając zestawów testowych stworzonych do testowania oryginalnych testów na ... poczekaj, gdzie znowu jestem?

— Uwaga dla siebie - wymyśl nazwę

Więc nie można przetestować vmware i podobnych programów?

— mlvljr

@mlvljr: To ważny punkt, ale myślę, że wykracza poza sferę „TDD”. Niewielu programistów ma dostęp do skryptowalnego, instrumentowanego emulatora na poziomie systemu. Miałem szczęście, że mam czterokanałowy lunetę!

— TMN

Osobiście uważam, że można uzyskać wiele korzyści z TDD (bez faktycznego przestrzegania TDD) poprzez:

Pisanie zarówno numeru dzwoniącego, jak i kodu odbiorcy w tym samym czasie (zdecydowanie nie więcej niż 24 godziny).
- I wykorzystaj to, aby wpłynąć na projekt interfejsu (obiekty, wywołania metod i parametry).
W przypadku komponentu wymagającego skomplikowanego algorytmu / kodu, zdecydowanie rozważ najpierw implementację prostszego, ale poprawnego algorytmu, nawet jeśli jest on mniej wydajny (lub głupi lub działa tylko w węższej sytuacji).
- Bardzo prostą metodą testowania byłoby uruchomienie obu algorytmów i porównanie ich wyników.
Po wykryciu błędu (w jakikolwiek sposób) w jednej części kodu, ta część kodu zasługuje na przetestowanie o wiele bardziej agresywnie. Oznacza to wykonywanie bardziej zaawansowanych testów, niż wymagałoby TDD. (na podstawie uzasadnienia, że błędy występują w klastrach )

TDD wydaje się wymagać od ciebie dość jasnego zrozumienia, jaką funkcję planujesz wdrożyć lub jakie wymagania planujesz spełnić, implementując kod. W niektórych sytuacjach po prostu zbyt mało rozumie się problemu. To wymagałoby rozwiązania Spike . W ramach tego rozwiązania Spike można zastosować TDD, ponieważ problem został zawężony do możliwego do zarządzania poziomu. Po ukończeniu kilku szczytów, z których każdy obejmuje niektóre aspekty pierwotnego problemu, można rozpocząć pracę nad pełnym rozwiązaniem, a zastosowanie TDD w tym momencie może być wykonalne ze względu na lepsze zrozumienie.

Edytowane:

Po dokładniejszym przeczytaniu strony

Chociaż powinno być możliwe przetestowanie większości funkcji jądra w sterowniku testowym „testbed”, tak naprawdę „soczyste” rzeczy, takie jak obsługa przerwań, wysyłanie procesów lub zarządzanie pamięcią, prawdopodobnie nie są testowane jednostkowo. --- z http://wiki.osdev.org/Unit_Testing

Wyraźnie mówią, że większość części jest testowalna i że niektóre części wymagają innego rodzaju testów: testów wytrzymałościowych .

— rwong
źródło

oznacza to również, że ważnymi częściami są te, które wymagają różnych badań imho.

— Bill

co za niesamowita odpowiedź! na niektórych poziomach pozdrawiam!

— manuelBetancurt

Ja nie. W kodzie wbudowanym mojego Mistrza po prostu piszę kod i spędzam czas na zastanawianiu się, co robi (a czego nie robi). W każdym razie nie jestem pewien, czy da się to zrobić. Zbliżam się niepokojąco do fizycznej granicy pamięci bez wstrzykiwania kodu testowego.

Myślę, że w przypadku systemów, które są wystarczająco duże (tj. Mają MB pamięci, a nie KB), można to zrobić w przypadku niektórych komponentów, jeśli masz wystarczająco dużo czasu i wysiłku. Testowanie kodu odczytu pinów przez wyśmiewanie pinów jest ... eee ... mało znaczące. Jeśli Twoja logika jest wystarczająco rozdzielona, możesz przetestować logikę w innym miejscu.

FWIW, nie kupuję TDD w ogólnym przypadku - działa dobrze dla stosów systemowych, które są wystarczająco duże z wystarczającymi zasobami o wystarczającym deterministycznym zachowaniu, poza tym nie wydaje się rozsądną praktyką.

— Paul Nathan
źródło