Ano ang Test Driven Development, approach at advantages

Ang Test Driven Development (TDD) ay isang software development approach kung saan ang mga test case ay binuo upang tukuyin at patunayan kung ano ang gagawin ng code.

Ang halos mga kaso ng pagsubok para sa bawat tampok ay nilikha at nasubok bago ilabas ang software, at kung nabigo ang pagsubok, ang bagong code ay isusulat (o muling isinulat o i-patch) upang maipasa ang pagsubok at gawing simple at walang bug ang code.

Ang Test Driven Development (TDD) ay nagsisimula sa pagdidisenyo at pagbuo ng mga pagsubok para sa bawat maliit na feature sa isang application. Ang TDD framework ay nagtuturo sa mga developer na magsulat lamang ng bagong code kung ang isang awtomatikong pagsubok ay nabigo. Iniiwasan ng diskarteng ito ang pagdoble ng code. Ang kumpletong TDD module ay test-driven na development.

Ang Test Driven Development (TDD) ay nagmula bilang bahagi ng mas malaking paradigm sa disenyo ng software na kilala bilang Extreme Programming (XP), na bahagi ng Agile software development methodology.

Ang simpleng konsepto ng TDD ay ang pagsulat at pag-aayos ng mga nabigong pagsubok bago magsulat ng bagong code (bago ang pagbuo). Nakakatulong ito na maiwasan ang pagdoble ng code habang nagsusulat kami ng maliit na halaga ng code sa isang pagkakataon upang makapasa sa mga pagsubok. (Ang mga pagsusulit ay hindi hihigit sa mga kondisyong kinakailangan na kailangan nating subukan upang matugunan ang mga ito).

Test-driven development ay isang proseso ng pagbuo at pagpapatakbo ng mga automated na pagsubok bago ang aktwal na pag-develop ng application. Samakatuwid, ang TDD ay tinatawag ding Test First Development.

Mga yugto ng diskarte sa TDD

Bago magsulat ng anumang bagong code, ang programmer ay dapat munang gumawa ng bagsak na unit test. Pagkatapos, ang programmer - o mag-asawa, o mob - ay lumilikha lamang ng sapat na code upang matugunan ang pangangailangang iyon. Kapag pumasa ang pagsubok, maaaring i-refactor ng programmer ang proyekto, gumawa ng mga pagpapabuti nang hindi binabago ang pag-uugali.

Habang nakatuon ang TDD sa mga pakikipag-ugnayan ng programmer sa antas ng unit, may iba pang sikat na pamamaraan, gaya ng acceptance test-driven development (ATDD) o behavior-driven development (BDD), na tumutuon sa mga pagsubok na mauunawaan ng mga customer.

Ang mga pamamaraang ito ay kinabibilangan ng pagbuo ng mga tunay na halimbawa sa mundo bilang mga collaborative na pagsubok sa pagitan ng engineering staff at ng customer bago mag-coding, at pagkatapos ay patakbuhin ang mga pagsubok pagkatapos mag-coding upang ipakita na ang code ay ipinatupad. Ang pagkakaroon ng mga pagsubok na alam nang maaga ay nagpapabuti sa kalidad ng unang pagkakataon. Ang ATDD at BDD ay nangangailangan ng mga developer, tester at ang panig ng negosyo na magtulungan upang isipin at talakayin ang software at ang mga implikasyon nito bago magawa ang code.

Mga kalamangan ng TDD

Ang pag-unlad na hinimok ng pagsubok ay maaaring makagawa ng mga de-kalidad na aplikasyon sa mas kaunting oras kaysa posible sa mga mas lumang pamamaraan. Ang matagumpay na pagpapatupad ng TDD ay nangangailangan ng mga developer at tester na tumpak na mahulaan kung paano gagamitin ang application at ang functionality nito sa totoong mundo.

Bumubuo ang TDD ng regression test suite bilang isang side effect na maaaring mabawasan ang manu-manong pagsubok ng tao, paghahanap ng mga problema nang mas maaga, na humahantong sa mas mabilis na mga solusyon. Ang likas na pamamaraan ng TDD ay nagsisiguro ng mas mataas na first-time na saklaw at kalidad kaysa sa mga klasikong phased code cycles > test > fix > retest. Dahil ang pagsubok ay isinasagawa nang maaga sa ikot ng disenyo, ang oras at pera na ginugol sa pag-debug sa ibang pagkakataon ay mababawasan.

Mga inaasahang benepisyo:

• makabuluhang pagbawas sa mga rate ng depekto, sa halaga ng isang katamtamang pagtaas sa paunang pagsisikap sa pag-unlad
• Ang mga gastos sa overhead ay higit pa sa binabayaran ng pagbawas sa pagsisikap sa mga huling yugto ng mga proyekto
• Ang TDD ay humahantong sa mas mahusay na mga katangian ng disenyo sa code at, sa pangkalahatan, mas mataas na antas ng "internal" o teknikal na kalidad, halimbawa sa pamamagitan ng pagpapabuti ng cohesion at coupling metrics

Mga disadvantages ng TDD

Ang TDD ay nangangailangan ng malaking kasanayan upang maging matagumpay, lalo na sa antas ng yunit. Maraming mga legacy system ang simpleng hindi binuo na nasa isip ang unit testing, na ginagawang imposibleng ihiwalay ang mga bahagi para sa pagsubok.

Gayundin, maraming programmer ang kulang sa kakayahan upang ihiwalay at lumikha ng malinis na code. Ang lahat ng miyembro ng team ay dapat gumawa at magpanatili ng mga unit test o sila ay mabilis na magiging lipas na. At ang isang organisasyong tumitingin sa TDD ay kailangang maglaan ng oras, magdahan-dahan nang kaunti ngayon para mas mabilis mamaya.

Sa wakas, tulad ng anumang pamamaraan, ang mga huling resulta ng TDD ay kasinghusay lamang ng mga pagsubok na ginamit, kung gaano katumpak ang mga ito na isinagawa, at ang lawak kung saan ginagaya ang mga kundisyong naranasan ng mga gumagamit ng huling produkto.

Mga karaniwang pagkakamali:

• nakakalimutang magpatakbo ng mga pagsusulit nang madalas
• sumulat ng napakaraming pagsubok nang sabay-sabay
• sumulat ng mga pagsusulit na masyadong malaki o mahalay
• pagsulat ng labis na walang kabuluhang pagsusulit, tulad ng pag-alis ng mga pahayag
• sumulat ng mga pagsubok para sa maliit na code
• bahagyang pag-aampon: ilang developer lang sa isang working group ang gumagamit ng TDD
• mahinang pagpapanatili ng test suite, kadalasang humahantong sa isang test suite na may matagal na panahon
• inabandona ang test suite (ibig sabihin, bihira o hindi tumakbo) – minsan dahil sa hindi magandang maintenance, minsan dahil sa turnover ng team

pilosopiya ng TDD

Pinapayagan ng TDD ang programmer na gumawa ng mga hakbang sa sanggol kapag nagsusulat ng software. Isinulat ang pagsusulit bago subukan ang functionality at tinitiyak na ang application ay angkop para sa testability. Ang pagsubok sa isang maliit na halaga ng code ay ginagawa upang mahuli ang mga error na nangyayari sa nasubok na code. Pagkatapos ay ipinatupad ang pag-andar. Ito ay tinutukoy bilang isang "red green refactor" kung saan ang pula ay nangangahulugang pagkabigo at berde ay nagpapakita ng pass. Ang mga hakbang na ito ay paulit-ulit. Ang unang layunin ng isang programmer ay mag-focus sa gawaing nasa kamay at mapagtagumpayan ito.

Ang iba't ibang yugto na kasangkot sa isang ikot ng pag-unlad na hinimok ng pagsubok ay:

• Magdagdag ng Pagsubok: Ang bawat bagong feature sa TDD ay nagsisimula sa isang pagsubok na dapat mabigo habang inilalagay ito bago ipatupad ang anumang feature. Ang kinakailangan para sa pagsulat ng pagsubok bago ang pagpapatupad ng tampok ay isang malinaw na pag-unawa sa kinakailangan ng developer. Ito ay nakakamit sa pamamagitan ng mga kwento ng gumagamit at mga kaso ng paggamit. Kaya nauunawaan ng isang developer ang kinakailangan bago isulat ang code ng programa.
• Patakbuhin ang lahat ng pagsubok at suriin kung nabigo ang bagong code: tinitiyak nito na gumagana nang tama ang test harness at hindi mabibigo ang bagong pagsubok nang walang anumang bagong code. Bine-verify din ng hakbang na ito ang pagsubok at inaalis ang posibilidad na palaging papasa ang bagong pagsubok.
• Sumulat ng Code: Ang susunod na hakbang na sumusunod ay ang pagsusulat ng code na lumilinaw sa pagsubok. Ang bagong code ay hindi perpekto ngunit sa ibang pagkakataon ay binago ayon sa mga kinakailangan. Ito ay dinisenyo para lamang sa pagsubok at walang iba pang mga tampok.
• Magpatakbo ng Mga Automated Test: Kung ang bawat test case na ginawa ay madaling pumasa sa pagsubok, nangangahulugan ito na natutugunan ng code ang lahat ng kinakailangang mga detalye. Pagkatapos ang huling yugto ng cycle ay maaaring magsimula.
• Refactoring code: Ito ay katulad ng pag-alis ng duplikasyon. Hindi sinisira ng refactoring ang anumang umiiral nang functionality at nakakatulong na alisin ang duplikasyon sa pagitan ng production at test code. Nililinis na ngayon ang code kung kinakailangan.
• Ulitin: Ang cycle ay umuulit tulad ng sa mga nakaraang kaso na may bagong pagsubok. Ang mahalagang kinakailangan ay ang laki ng hakbang ay maliit, na may humigit-kumulang 1-10 pagbabago sa pagitan ng bawat pagsubok na pagtakbo. Kung ang bagong code ay nabigo sa isang bagong pagsubok, ang programmer ay dapat gumawa ng higit pang pag-debug. Ang patuloy na pagsasama ay nagbibigay ng nababaligtad na mga checkpoint.

Ercole Palmeri