Narzędzie używane przez cały show nie może zepsuć się w środku dnia — jak pipeline testuje sam siebie, zanim zmiana trafi do artystów.
Rozdział 9 wyjaśnił, dlaczego kod pipeline'u przechodzi przez branch i code review, zanim trafi do artystów — stawka błędu jest wyższa niż w typowym małym zespole software'owym. Ten dodatek pokazuje mechanizm, który stoi obok recenzji człowieka: zautomatyzowane testy uruchamiane przy każdej zmianie, zanim jeszcze ktokolwiek zdąży ją przejrzeć ręcznie.
v001 od v10.Typowy test w oprogramowaniu uruchamia się w ułamku sekundy, bez żadnych zewnętrznych zależności. Test smoke sprawdzający narzędzie pipeline'u często musi uruchomić prawdziwą Mayę czy Houdiniego w trybie headless (bez interfejsu graficznego) na maszynie CI — co oznacza dostępność licencji na tej maszynie, dłuższy czas startu samego DCC, i środowisko rozwiązane dokładnie tym samym menedżerem pakietów z Rozdziału 17, żeby test w ogóle odzwierciedlał to, czego doświadczy artysta. To właśnie ta specyfika sprawia, że CI w VFX bywa wolniejsze i trudniejsze do utrzymania niż w typowym projekcie webowym, mimo że sama idea jest identyczna.
Kluczowa własność CI, odróżniająca je od zwykłego „uruchom testy, jak będziesz miał czas": pull request z Rozdziału 9 fizycznie nie da się połączyć z branchem produkcyjnym, dopóki wszystkie zarejestrowane testy nie przejdą. To zamienia dyscyplinę code review z dobrej praktyki w wymóg egzekwowany przez samo narzędzie, nie tylko przez kulturę zespołu — i daje Pipeline TD (Rozdział 21) konkretną podstawę do tego, żeby z pewnością przypiąć nowy tag narzędzi (Rozdział 17) do żywego showu, zamiast polegać wyłącznie na tym, że ktoś „na oko" sprawdził zmianę.