Znalazłem ostatnio książkę pt. Test-Driven Development for Embedded C i zastanawiam się czy w branży systemów wbudowanych takie podejście jest w ogóle możliwe?
Bo np. w embedded często jest komunikacja czy to przewodowa czy bezprzewodowa. Jak w ogóle możliwe jest napisanie testów i przetestowanie aplikacji bez fizycznego sprzętu?
1
3
Bardzo prosto, mockować te urządzenia czy to na poziomie aplikacji czy też sterownika. W skrajnym przypadku mógłby to być nawet sprzętowy mock. Zerknij może do kodu coreboota (boot firmware), tam jest troche testów.
0
Mockować, czyli przedrzeźniać, naśladować tak? Bo np. zastanawiam się nad takim przykładem:
HAL_CAN_Transmit() oraz HAL_GPIO_WritePin(), obie dla mikrokontrolerów stm32. Jedna jest związana z transmisją po CANie natomiast druga wymusza stan na danym pinie.
Zastanawiam się jak by wyglądał test napisany dla tych funkcji.
Bo zanim napiszę test to muszę wiedzieć jakiego rezultatu oczekuję prawda?
1
HAL_GPIO_WritePin() nie jest raczej funkcją, którą powinieneś testować jednostkowo - to chyba nie jest w ogóle twój kod, tylko jakiejś biblioteki, nie ufasz im? ;)
0
Bo generalnie wszystkie funkcje w embedded robią jedną z dwóch rzeczy: a) wpisz jakąś wartością do rejestra X b) odczytaj wartość z rejestra Y
Wiem, 90% rzeczy ma efekty uboczne (fizyczne). Ale tutaj to akurat proste: wpisujesz wartość do rejestru, a potem odczytujesz i patrzysz, czy jest tam to, co wpisałeś. Jak tak - dobrze. Jak nie - źle. Ale w ogóle bym tego tak nie robił!
Wpisanie wartości do rejestru, ustawienie (czy odczyt) GPIO, wysłanie wiadomości do szyny, transfer danych, czy co tam innego to tylko ostatnie składniki logiki aplikacji. A to twoją logikę trzeba testować (jednostkowo), a nie czy funkcja ustawiająca GPIO faktycznie je ustawiła (bo w zasadzie testujemy integracyjnie...).
Czyli jeżeli twoja aplikacja odczytuje stan wejścia, a potem robi coś i w zależności od tego ustawia wyjście A lub B to test piszesz tylko że: "dla wejścia o wartości 0 wyjście powinno być A, dla wejścia o wartości 1 wyjście powinno być B" i tak też robisz swoją funkcję. Możesz tutaj rzeczywiście zrobić mock i mieć w swojej funkcji "odpalanie" rzeczywistego wysłania danych - ale w teście uruchamia się tylko fikcyjne wysyłanie danych.
0
No dobra, ale jaki ma realny sens test (jednostkowy) wpisu do rejestru, jeśli tam nie ma żadnej logiki? To się powinno robić (i się robi) w testbenchu w jakimś HDLu, potem ew. na sprzęcie na poziomie instrukcji maszynowych/asma. No bo tak realnie - testowanie czegoś takiego jak wpis do rejestru do de facto testowanie kompilatora czy wygeneruje dobrą instrukcję. Jeżeli tam jest jakaś logika, liczenie CRC itd. to inna sprawa.
3
@Mirai: API systemowego się nie testuje. Funkcji pozbawionych logiki też nie trzeba.