Im więcej pracuję w WordPressie, tym bardziej staram się, aby testowanie jednostkowe było tak samo częścią mojego rozwoju, jak tworzenie rzeczywistego zestawu funkcji. (W każdym razie wszyscy profesjonaliści twierdzą, że musimy to zrobić.)
Ale poważnie, to poprawia jakość, ponieważ, jeśli nie z innego powodu, coś się zepsuje, możesz zobaczyć, który test się nie powiedzie, a nawet jeśli przegapiłeś zasięg w jakimś obszarze.
Nie jestem przekonany, że niektórzy muszą mieć 100% pokrycie kodu (i są powody, dla których tak uważam), ale uważam, że ważne jest, aby mieć jak najwięcej pokrycia kodu, który nie jest bezpośrednio do WordPressa.
Testowanie kodu w WordPress
Nie wiem, czy brzmi to dezorientująco, czy nie, ale jedną z pułapek, w które wpadłem na początku pracy z testami jednostkowymi i WordPress, było pisanie testów na podstawowy kod WordPressa.
Nadal czasami to robię (a możesz zapytać tych, z którymi pracuję, czy to prawda), choć coraz lepiej.
Jeśli o mnie chodzi, sam WordPress można potraktować jako czarną skrzynkę. To podstawa, na której opiera się Twoja aplikacja. Istnieją już testy wokół rdzenia WordPressa. Czy powinno być więcej? Pewny. Czy to, co mają, wystarczy? Z mojego doświadczenia wynika, że tak, ale wszyscy używamy innego podzbioru wspomnianych funkcji.
Rozumiem to tak: Za każdym razem, gdy pracujesz nad projektem opartym na WordPressie; nie musisz pisać testów z kodem takim jak add_menu_pagelub wp_enqueue_script.
Wiemy, że te funkcje działają.
Zamiast tego skup się na kodzie specyficznym dla Twojej domeny. Oznacza to, że skoncentruj się na kodzie, który piszesz ty i twój zespół. Będzie to obszar specjalizacji, który jest unikalny w projekcie i będzie to obszar, który ostatecznie odpowiada za rozwiązanie danego problemu.
Jeśli chcesz uzyskać 100% pokrycie tylko ze względu na 100% pokrycie, to nie piszesz testów jednostkowych z właściwego powodu. Zamiast tego dąż do najwyższego stopnia pokrycia kodu, który wystarczająco testuje Twój kod. To wymusza jakość.