Test Driven Development na míru snadno a rychle

Test Driven Development na míru snadno a rychle Seznam všech příspěvků

„Teď jsem tam změnil jenom drobnost, to už přece musí fungovat.“ Tuhle větu slýchám od studentů často a místo víry by se jim hodil test. Přednáška na linuxové konferenci LinuxDays na ČVUT FIT proto ukazuje jednoduché automatizované testování, které může ve svém projektu použít každý, ať už testuje software v libovolném jazyce, nebo celé systémy. Bez učení se nějakého frameworku, jen s pár řádky v shellu a nástroji, které už v systému máte. Tentokrát na přednášku navazoval i workshop, kde si účastníci všechno prakticky vyzkoušeli.

Pomocí jednoduchých nástrojů a jejich kombinací v shellu snadno otestujete, že nová verze kódu nebo systému funguje alespoň stejně dobře jako ta předchozí, nebo že zrychlení programu nebylo na úkor funkčnosti. Pro nováčky na FIT je to zároveň ochutnávka a motivace pro předmět Unixové operační systémy (BI-UOS).

Přednášku můžete sledovat ze záznamu LinuxDays, workshop se nenahrával.

Hlavní myšlenky

  • TDD je pro líné programátory. Nejdřív napíšu test, který (logicky) neprojde, pak jen tolik kódu, aby prošel, a teprve potom případně vylepšuji (red – green – refactor). Neřeší se, jestli by to šlo napsat elegantněji nebo robustněji: když to prochází testy, je to dobře.
  • Psaní testů je vlastně návrh. Když si předem rozmyslím, v jakých situacích a jak má program fungovat, vyřeším spoustu problémů dřív, než vzniknou. Testy pak slouží jako minimum dokumentace rozhraní a dávají jistotu při každé další změně.
  • Nic není zadarmo. Testy jsou další kód, který je potřeba udržovat, vyžadují disciplínu a často i testovací prostředí. A největší nebezpečí je falešný pocit bezpečí: kód je jen tak dobrý, jak dobré jsou testy.
  • Testujte výsledek, ne postup. Když se testy dopisují až k hotové implementaci, testují tu implementaci, a ne to, co se po programu chce. Řetězí se pak do sebe a lžou. Test má ověřit, že na konci existuje adresář a v něm soubor, ne jestli se cestou volal mkdir, cd a touch.
  • Testy musí být nezávislé. Každý běh potřebuje čistý start: dočasný adresář z mktemp, úklid po sobě, nebo rovnou kontejner (podman), který navíc chrání vlastní systém i data před chybou ve vyvíjeném skriptu.
  • Pozor na zrádnosti shellu. $? po koloně příkazů je návratový kód posledního z nich (pomůže PIPESTATUS nebo pipefail), $( … ) ořízne konce řádků a do proměnné se nevejde nulový bajt (pomůže třeba base64).
  • Začněte v malém. Pokud váš jazyk má vlastní testovací nástroje, používejte je. Vlastní testovátko na pár řádků se ale hodí ve chvíli, kdy nepoužíváte nic a nechcete se učit cizí syntaxi ani přizpůsobovat se filozofii nějakého nástroje. Prostě jen nechcete testovat ručně.

Obsah přednášky

Odkazy vedou na příslušný slide prezentace a čas ve videu, kde část začíná.

  1. Minimum teorie 00:02:14
  2. Co testovat 00:11:28
  3. Jak testovat 00:27:01
  4. Typické problémy 00:39:16
  5. Testovací framework 00:50:14
  6. Jak simulovat (mock: alias, funkce, skript, služba)
  7. Dotazy 00:50:51
    testy v shellu vs. testovací nástroje vlastního jazyka, ShellSpec

Ani letos jsem nestihl všechno. Na testovací framework zbyla jen pozvánka na workshop, kde jsme si ho rovnou napsali, a kapitola o simulování okolí pomocí mocků zůstala jen ve slidech.

Workshop

Repozitář se skripty a daty k workshopu

Na workshopu jsme testovali různé verze softwaru v typických situacích a každý si napsal svůj vlastní primitivní testovací framework na pár řádků, který si posléze může na míru upravit pro vlastní projekt:

  1. Základní testy — $?, test, cmp
  2. White/black list — grep, comm, diff
  3. Test parametrů — vlastní framework
  4. Test souborů v kontejneru — podman

Repozitář obsahuje jednotlivé kroky workshopu po kouscích (skripty, testy i data), takže si všechno můžete vyzkoušet i doma.