Jak zrobić TDD ze sprzętem

Wszystkie projekty, które pracuję, są interfejsem do jakiegoś sprzętu i często jest to główny cel oprogramowania. Czy są jakieś skuteczne sposoby na zastosowanie TDD do kodu, który działa ze sprzętem?

Update: Przepraszam, że nie wyraziłem się jaśniej w moim pytaniu.

Sprzęt, którego używam, to uchwyt ramek, który przechwytuje obrazy z aparatu. Następnie przetwarzam te obrazy, wyświetlam je i zapisuję na dysku. Mogę symulować całe przetwarzanie, które odbywa się po obrazach są przechwytywane za pomocą wcześniej przechwyconych obrazów, które są przechowywane na dysku.

Ale to prawdziwa interakcja ze sprzętem, którą chcę przetestować. Na przykład Czy moje oprogramowanie radzi sobie poprawnie, gdy nie ma dołączonej kamery, czy prawidłowo uruchamia się i przestaje chwytać itp. Ale to jest tak związane ze sprzętem, że nie wiem, jak go przetestować, gdy sprzęt nie jest obecny lub czy powinienem w ogóle próbować to zrobić?

2. Update: ja też szukam jakiegoś konkretnego przykłady dokładnie jak ludzie radzili sobie z tą sytuacją.

Author: Matt Warren, 2009-02-25
Source

7 answers

Podziel swój zestaw testów na dwie części:

  1. Pierwsza część przeprowadza testy na prawdziwym sprzęcie. Ta część służy do budowy makiet. Pisząc do tego automatyczne testy, możesz je uruchomić ponownie, jeśli masz jakiekolwiek wątpliwości, czy Twoje makiety działają poprawnie.

  2. Druga część biegnie na tle makiet. Ta część działa automatycznie.

Część #1 jest uruchamiana ręcznie po upewnieniu się, że sprzęt jest prawidłowo podłączony itp. Dobrym pomysłem jest Utwórz zestaw testów, które działają na coś zwróconego przez fabrykę i uruchom te testy dwa razy: raz z fabryką, która zwraca prawdziwy "sterownik" i raz przeciwko fabryce Twoich mock obiektów. W ten sposób możesz być pewien, że Twoje kpiny działają dokładnie tak, jak prawdziwe: {]} 

class YourTests extends TestCase {
    public IDriver getDriver() { return new MockDriver (); }
    public boolean shouldRun () { return true; }
    public void testSomeMethod() throws Exception {
        if (!shouldRun()) return; // Allows to disable all tests
        assertEquals ("1", getDriver().someMethod());
    }
}

W moim kodzie zwykle używam właściwości systemowej (- Dmanual = yes) do przełączania testów ręcznych: 

class HardwareTests extends YourTests {
    public IDriver getDriver() { return new HardwareDriver (); }
    public boolean shouldRun () { return "yes".equals (System.getProperty("manual")); }
}
 3
Author: Aaron Digulla,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-02-25 12:23:07

Utwórz cienką warstwę do sterowania sprzętem i użyj testów systemu (ręcznych lub automatycznych) z pełnym sprzętem, aby upewnić się, że warstwa kontrolna działa zgodnie z oczekiwaniami. Następnie utwórz fałszywą / pozorną implementację warstwy kontrolnej, która zachowuje się zewnętrznie jak interfejs do rzeczywistego sprzętu i używaj jej podczas wykonywania TDD przez resztę programu.

Lata temu pisałem oprogramowanie do wykonywania pomiarów magnetometrem SQUID. Sprzęt był duży, nieusuwalny i drogie ( video ), więc nie zawsze można było mieć dostęp do sprzętu. Mieliśmy dokumentację dotyczącą protokołu komunikacji z urządzeniami (poprzez porty szeregowe), ale dokumentacja nie była w 100% dokładna.

Bardzo pomogĺ 'o nam stworzenie oprogramowania, ktĂłre nasĺ' uchuje danych pochodzÄ ... cych z jednego portu szeregowego, rejestruje je i przekierowuje na inny port szeregowy. Następnie udało nam się dowiedzieć, w jaki sposób stary program (który zastępowaliśmy) komunikował się z sprzęt, i inżynieria odwrotna protokołu. Były one przykute tak: stary Program wirtualny port szeregowy Loopback nasz rejestrator danych prawdziwy Port Szeregowy Sprzęt.

Wtedy nie używaliśmy TDD. Rozważaliśmy napisanie emulatora dla sprzętu, abyśmy mogli przetestować program w izolacji, ale ponieważ nie wiedzieliśmy dokładnie, jak sprzęt ma działać, trudno było napisać dokładny emulator, więc w końcu tego nie zrobiliśmy. Gdybyśmy znali sprzęt lepiej, moglibyĺ "my stworzyÄ ‡ dla niego emulator, co znacznie uĹ 'atwiĺ' oby rozwĂłj programu. Testowanie z prawdziwym sprzętem było najcenniejsze, a z perspektywy czasu powinniśmy poświęcić jeszcze więcej czasu na testowanie ze sprzętem.

 7
Author: Esko Luontola,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-02-25 12:11:49

Jeśli piszesz oprogramowanie do manipulowania danymi pochodzącymi ze specjalistycznego sprzętu, możesz rozsądnie stworzyć stand-in dla sprzętu do testowania oprogramowania.

Jeśli interfejs sprzętowy jest czymś prostym, jak Port Szeregowy, możesz łatwo użyć kabla z pętlą, aby twój program rozmawiał ze sprzętem. Stosowałem to podejście kilka lat temu, pisząc oprogramowanie do rozmowy z procesorem kredytowym. Moja aplikacja testowa została podana, aby myśleć, że mój symulator był modem i procesor back-end.

Jeśli piszesz sterowniki urządzeń PCI lub oprogramowanie równoważnego poziomu, to prawdopodobnie nie możesz utworzyć oprogramowania stand-in.

Jedynym dobrym sposobem zastosowania TDD do takich problemów jest sfałszowanie we/wy sprzętu za pomocą innego programu. Na przykład, pracuję z obsługą kart kredytowych na stacjach benzynowych. Na moim obecnym projekcie mamy symulator, który jest Elektronika pompy podłączony do niektórych przełączników takich, że działanie pompy (uchwyt podnoszenia, naciśnięcie spustu, przepływ paliwa) mogą być symulowane. To całkiem możliwe, że moglibyśmy zbudować symulator, który byłby sterowany przez oprogramowanie.

Alternatywnie, w zależności od urządzenia, można użyć standardowego sprzętu testowego (Generatory sygnału itp.), aby zasilać je "znanymi wejściami".

Zauważ, że problem polega na tym, że testujesz zarówno sprzęt, jak i sterowniki urządzeń razem. Niestety, to naprawdę jedyny dobry wybór, jaki masz na tym etapie-każdy symulowany sprzęt prawdopodobnie będzie różnił się na tyle od rzeczywistego sprzętu, że będzie bezużyteczny do testowania.

 4
Author: Michael Kohne,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-02-25 11:41:43

To prawdopodobnie nie jest dobry pomysł, aby włączyć testy, które mają dostęp do sprzętu w zestawie testów. Jednym z problemów z tym podejściem jest to, że testy będą mogły działać tylko na maszynie, która jest podłączona do tego specjalnego sprzętu, co utrudnia Uruchamianie testów powiedzmy jako część (nocnego) automatycznego procesu budowania.

Jednym z rozwiązań może być napisanie modułów programowych, które zachowują się jak brakujące moduły sprzętowe, przynajmniej z punktu widzenia interfejsu. Podczas uruchamiania pakietu testowego uzyskaj dostęp do tych modułów oprogramowania zamiast rzeczywistego sprzętu.

Podoba mi się również pomysł podzielenia zestawu testów na dwie części:

    Taki, który uzyskuje dostęp do prawdziwego sprzętu, który uruchamiasz ręcznie]}
  • taki, który uzyskuje dostęp do modułów oprogramowania, który działa jako część automatycznego testowania

Z mojego doświadczenia wynika, że testy związane z prawdziwym sprzętem prawie zawsze wymagają pewnej ilości ręcznej interakcji (np. podłączyć coś do sprawdź, czy jest poprawnie wykryty), co bardzo utrudnia automatyzację. Korzyści często nie są warte zachodu.

 2
Author: geschema,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-02-27 10:17:49

Szydzić sprytnie.

 1
Author: adolfojp,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-02-25 11:21:14

Kiedy pracowałem nad set - top boxami mieliśmy narzędzie, które generowałoby mocki z dowolnego API C z komentarzami doxygen.

Następnie wyśmiewaliśmy to, co chcieliśmy, aby sprzęt wrócił, aby przetestować nasze komponenty.

Więc w powyższym przykładzie Ustawiłeś wynik framegrabber_api_isdeviceattached na false, A gdy twój kod wywoła tę funkcję, zwraca false i możesz ją przetestować.

Jak łatwo będzie przetestować zależy od tego jaki będzie kod obecnie skonstruowany jak.

Narzędzie, którego użyliśmy do wygenerowania kpin, było w domu, więc nie mogę ci z tym pomóc. Ale są jakieś nadzieje na Google hit: (disclaimer-użyłem żadnego z nich, ale mam nadzieję, że mogą Ci pomóc)

Just sprawdzanie-czy masz coś w rodzaju bezpośrednich połączeń ioctl w kodzie czy coś? Zawsze trudno je sfałszować. Mieliśmy warstwę wrappera OS, dla której mogliśmy łatwo pisać mocki, więc było to dla nas dość łatwe.

 1
Author: Andrew Barrett,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-02-28 22:03:31

Jeśli masz symulator, możesz napisać testy na symulatorze i uruchomić te testy na sprzęcie.

Trudno odpowiedzieć na pytania z tak małym szczegółem: -)

 0
Author: Wouter Lievens,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-02-25 11:11:20