Modulové testování embedded: principy

Modulové testování v embedded vývoji: principy a praxe

Modulové testování ve firmware pro embedded systémy umožňuje kontrolovat funkčnost kódu, usnadňuje refactoring a dokumentuje API. Autor kódu napíše základní sadu testů, kolegové pak přidají nezávislé kontroly. To je obzvláště důležité pro protokoly jako UDS s požadavky na DTC.

Výhody zavádění modulových testů

Modulové testy znamenají volání funkce s pevnými argumenty a ověření výsledku, podobně jako SIL. Řeší několik úkolů:

• Kontrola funkčnosti: test potvrzuje, že kód funguje správně.
• Bezpečný refactoring: změny nezničí stávající kód.
• Dokumentace: příklady použití jsou vidět přímo v testech bez zbytečných komentářů.
• Kritérium dokončení: přechod k dalšímu modulu až po úspěšném projití testů.
• Kontrola výkonu: týmový lídr může definovat testy pro ověření příspěvku vývojáře.

Testy odlehčují odpovědnost autora: pokud kód testy projít včera, chyba je jinde. Odhalují nedosažitelný kód při měření pokrytí a podporují modulární strukturu, čímž se vyhýbáte spaghetti kódu s cyklogickými funkcemi a magickými čísly.

Analogii s PCB: testovací pady se navrhují už ve schématu, ne až po pájení. Ve softwaru stejně – pište malé funkce hned od začátku. Testy zaručují přenositelnost na platformy (ARM Cortex-M, RISC-V, PowerPC) a kompilátory (GCC, IAR, Clang). Regresní testování chytá poruchy starého kódu novými změnami.

Spouštění testů je zdarma a rychlé, na rozdíl od manuálního testování s kognitivními zkresleními. Pro manažery je to metrika pokroku. Ladění se zjednoduší: report testů ukáže problematickou funkci.

Nevýhody a řešení

Modulové testy mají limity, ale standardními praktikami se řeší.

• Paměť pro testy: na MCU s malým Flash rozdělte testy do skupin, spusťte postupně přes bootloader a CLI. Automatizujte v CI/CD (Jenkins). Alternativa – testujte na MCU s větším Flash, kopírujte funkční kód.

• Chyby v testech: proveďte code review, pište testy odolné vůči selháním.

• Přebytečnost: orientujte se na pokrytí kódu (nástroje jako Testwell CTC++) nebo technické požadavky. Test jen na požadavek.

• Nepokrývají integraci: doplňte integračními testy. Memes o uTest dveří v metru ilustrují: unit testy systém negarantují.

Principy psaní modulových testů

Autor modulu napíše první sadu – zná doménu. Oddělte kód a testy do složek.

• Každý test ověřuje jednu věc.
• Před opravou bugu – napište na něj test.
• Determinismus: bez rand(), pevné vstupy.
• Jednoduchost: krátký, čitelný, na jednu obrazovku.
• AAA: Arrange (příprava), Act (akce), Assert (ověření).
• Bez if – používejte ASSERT makra.
• Testujte hraniční případy.
• Integrace do CI, spouštění přes CLI (UART).
• Odolnost vůči refaktoringu.
• Pořadí testů neovlivňuje výsledek.
• Spouštění na targetu (HIL) přes Shell/Putty.

Testy buď fungují, nebo se mažou. Oprava má prioritu před produkčním kódem. Nezávislé testy od kolegů zlepšují pokrytí.

Složitost testovacího systému může překročit produkt, jako při testování audiokodeků (SGTL5000, MAX9860). Disciplína se vrátí spolehlivostí.

Co je důležité

• Modulové testy zavádějte od začátku vývoje pro modularitu a přenositelnost.
• Pište testy sami: hlubší pochopení urychlí proces.
• Používejte AAA a determinismus pro spolehlivost.
• Spouštění na targetu přes CLI – klíč k HIL.
• Doplňte integračními testy pro celkový pohled.

— Editorial Team