Ar vieneto bandymai verta pastangų?

Aš stengiuosi integruoti vieneto testavimą į kūrimo procesą komandoje, kurioje dirbau, ir yra keletas skeptikų. Kokie yra geri būdai įtikinti skeptiškus kūrėjus vieneto testavimo vertės komandoje? Mano konkrečiu atveju pridedame vieneto testus, pridedant funkcionalumą ar klaidas. Deja, mūsų kodų bazė neleidžia lengvai patikrinti.

573
16 сент. nustatė Ross Fuhrman 16 sept. 2008-09-16 00:44 '08 0:44 2008-09-16 00:44
@ 44 atsakymai
  • 1
  • 2

Kasdien mūsų biure vyksta mainai, kurie atrodo taip:

„Žmogus, man patinka vieneto testai, aš ką tik padariau krūva pakeitimų, kaip kažkas veikia, ir tada galėjau patvirtinti, kad nieko nepadarau, patikrindamas bandymą dar kartą ...“

Informacija kasdien keičiasi, tačiau nuotaika nekinta. Vieneto testai ir testų kūrimas (TDD) turi tiek daug paslėptų ir asmeninių privalumų, taip pat akivaizdžių, kad jūs negalite ką nors paaiškinti, kol jie patys tai darys.

Bet ignoruojant, čia yra mano bandymas!

  • Vieneto testai leidžia greitai atlikti kodo pakeitimus. Jūs žinote, kad jis veikia dabar, nes atliekate bandymus, kai atliekate būtinus pakeitimus, turite dar kartą atlikti bandymus. Tai taupo valandas.

  • TDD padeda suprasti, kada sustabdyti kodavimą. Jūsų testai suteikia jums garantiją, kad jūs padarėte pakankamai laiko ir galite sustabdyti derinimą ir pereiti prie kito.

  • Bandymai ir kodas veikia kartu, kad pasiektų geresnį kodą. Jūsų kodas gali būti blogas. TESTAS gali būti blogas. TDD pasitikite tikimybe, kad abu bus blogai / klaidingai maži. Dažnai tai yra testas, kuriam reikia koreguoti, tačiau tai vis dar yra geras rezultatas.

  • TDD padeda užkoduoti vidurių užkietėjimą. Kai susiduriate su daugybe sunkių darbų, parašytų virš mūsų, bandymai leis jums greitai judėti.

  • Testavimo moduliai padės jums suprasti kodo, kuriuo dirbate, struktūrą. Vietoj to, kad parašytumėte kodą, kad galėtumėte ką nors padaryti, pradėkite aprašyti visas sąlygas, kuriomis atskleidžiate kodą ir kokių rezultatų tikitės iš jo.

  • Prietaiso testavimas suteikia jums tiesioginę vizualinę grįžtamąjį ryšį, mes visi mylime visų šių žaliųjų šviesų jausmą, kai tai darome. Tai labai malonu. Taip pat daug lengviau pasiimti vietą, kurioje sustojote po pertraukos, nes galite pamatyti, kur jūs turite - tai yra kita raudona šviesa, kuriai reikia pataisyti.

  • Priešingai nei įprastai matuojant matavimo vienetą, tai nereiškia, kad dvigubai daugiau kodų arba lėtesnis kodavimas. Jis yra greitesnis ir patikimesnis nei kodavimas be bandymų, kai tik jį pakabinsite. Bandymo kodas paprastai yra gana trivialus ir nesuteikia daug pridėtinės vertės tam, ką darote. Tai yra tas, apie kurį tikite tik tada, kai tai darote :)

  • Manau, kad tai buvo Fowler, kuris sakė: „Neatlikti testai, dažnai atliekami, yra daug geresni už tobulus testus, kurie niekada nėra parašyti“. Aš tai aiškinu kaip leidimą rašyti testus, kur manau, kad jie bus naudingiausi, net jei mano kodas liktų labai neišsamus.

  • Geri vienetiniai testai gali padėti dokumentuoti ir apibrėžti ką daryti.

  • Vienetas bandymai padeda naudoti kodą. Perkelkite savo kodą ir bandymus į naują projektą. Atnaujinkite kodą prieš atlikdami bandymus.

Dauguma darbų, kuriuose dalyvauju, vieneto testas neveikia (sąveika su žiniatinklio programų naudotoju ir pan.), Bet net ir šiuo atveju mes visi bandome šioje parduotuvėje ir esame labai laimingi, kai bandymai yra susieti. Negaliu pakankamai rekomenduoti šio požiūrio.

722
16 сент. atsakymas pateikiamas reefnet_alex rugsėjo 16 d 2008-09-16 01:06 '08, 1:06 am. 2008-09-16 01:06

Testavimo moduliai labai mėgsta eiti į sporto salę. Jūs žinote, kad tai jums tinka, visi argumentai yra prasmingi, todėl pradėsite dirbti. Yra pradinis skubėjimas, kuris yra puikus, bet po kelių dienų pradėsite stebėtis, ar turėtumėte jaudintis. Jūs praleisite valandą laiko, kad pakeistumėte drabužius ir bėgtumėte aplink žiurkėno ratą, ir nesate tikri, kad tikrai viską įvesite, išskyrus skausmingas kojas ir rankas.

Tada, praėjus maždaug vienai ar dviem savaitėms, kai tik praeina skausmas, prasideda Didžiojo termino požiūris. Jūs turite praleisti kiekvieną pabudimo valandą, bandydami gauti „naudingą“ darbą, todėl, pavyzdžiui, išpjaukite kitų dalykų, eikite į sporto salę. Jūs išnyko iš įpročio ir iki to laiko, kai baigiasi Didysis terminas, grįšite į pirmąjį. Jei vėl sugrįšite į sporto salę, pajusite tą patį skausmą, kaip jūs pirmą kartą išvykote.

Jūs skaitote, matote, kažkas negerai. Jūs pradėsite jaustis šiek tiek neracionalaus nusikaltimo visoms tinkamoms, laimingiems žmonėms, kurie praturtina pratimų dorybes. Jūs suprantate, kad neturite daug bendro. Jiems nereikia vairuoti 15 minučių, kad nuvyktų į sporto salę; jų pastate yra vienas. Jiems nereikia prieštarauti su jais dėl naudos; tai, ką kiekvienas daro ir pripažįsta svarbiu. Artėjant Didžiajam laikui, jiems nėra pasakyta, kad pratimas nereikalingas daugiau nei jūsų bosas paprašys nustoti valgyti.

Taigi, norint atsakyti į jūsų klausimą, vieneto testavimas yra verta pastangų, tačiau reikiamų pastangų suma nebus vienoda visiems. Testavimo moduliams gali prireikti didžiulės sumos, jei dirbate su spageti kodo baze kompanijoje, kuri faktiškai neįvertina kodo kokybės. (Daugelis vadybininkų dainuos vienetų testavimo balus, tačiau tai nereiškia, kad jie laikysis šio klausimo, kai tai yra svarbu.)

Jei bandote įvesti „Unit Testing“ į savo darbą ir nematote visų laukiamų saulės spindulių ir vaivorykštų, nekaltinkite. Galbūt jums reikės surasti naują užduotį, kad galėtumėte atlikti vieneto testavimą.

421
16 сент. atsakymas duotas benzado 16 rugsėjis 2008-09-16 06:53 '08 at 6:53 2008-09-16 06:53

Geriausias būdas įtikinti ... yra rasti klaidą, užsirašyti vieneto testą, pataisyti klaidą.

Tikėtina, kad ši klaida niekada nepasikartos, ir jūs galite tai įrodyti savo testu.

Jei tai padarysite, kiti greitai sugriebs.

136
16 сент. Ed Guiness atsakymas, pateiktas rugsėjo 16 d 2008-09-16 00:48 '08 ne 0:48 2008-09-16 00:48

klausia:

Kokie yra geri būdai įtikinti skeptiškus kūrėjus vieneto testavimo vertės komandoje?

Kiekvienas čia nukrenta dėl daugelio priežasčių, nes vieneto testavimas yra geras. Vis dėlto manau, kad dažnai geriausias būdas įtikinti ką nors iš jų yra išklausyti jų argumentus ir kreiptis į jį. Jei klausotės ir padedate jiems verbalizuoti savo problemas, galite kreiptis į kiekvieną iš jų ir galbūt juos paversti savo pačių požiūriu (arba bent palikti juos be kojos stovėti). Kas žino Galbūt jie įtikins jus, kodėl vieneto testai netinka jūsų situacijai. Labiausiai tikėtina, bet įmanoma. Galbūt, jei skelbiate argumentus prieš vienetų testus, galime padėti nustatyti priešinius argumentus.

Svarbu išklausyti ir suprasti abi argumento puses. Jei bandysite pernelyg sunku atlikti vieneto testus, nesirūpindami žmonėmis, jūs baigsite religinį karą (ir tikriausiai tikrai nenaudingas vieneto testus). Jei jį pamažu pradėsite ir pradėsite, kai matysite didžiausią naudą mažiausiomis sąnaudomis, galite parodyti vieneto testų vertę ir turėti geresnes galimybes įtikinti žmones. Suprantu, kad tai nėra taip paprasta, kaip atrodo - paprastai reikia šiek tiek laiko ir kruopščiai atlikti įtikinamą argumentą.

Vieni bandymai yra kaip bet kuris kitas įrankis ir turėtų būti taikomi taip, kad privalumai (spąstai) būtų didesni už išlaidas (jų rašymo pastangas). Nenaudokite jų, jei / kur jie neturi prasmės, ir nepamirškite, kad jie yra tik jūsų įrankių arsenalo dalis (pvz., Patikrinimai, pareiškimai, kodų analizatoriai, formalūs metodai ir tt). Sakau savo kūrėjams:

  • Jie gali praleisti metodo testo įrašą, jei jie turi gerą argumentą, kodėl tai nereikalinga (pavyzdžiui, pernelyg paprasta, ar pernelyg sunku kainuoti) ir kaip šis metodas būtų kitaip (pvz., Patvirtinimas, patvirtinimas, formalūs metodai, interaktyvūs / integravimo testai). Jie turi atsižvelgti į tai, kad kai kurie patikrinimai, pvz., Patikrinimai ir formalūs įrodymai, atliekami tam tikru momentu, o tada jie turi būti kartojami kiekvieną kartą keičiant gamybos kodą, o vieneto bandymai ir pareiškimai gali būti naudojami kaip regresijos testai (jie įrašomi vieną kartą) po to). Kartais su jais sutinku, bet dažniau aptarsiu, ar metodas tikrai yra pernelyg paprastas ar per sudėtingas, kad būtų galima atlikti vieneto testą.

    • Jei kūrėjas teigia, kad šis metodas atrodo pernelyg lengvas, ar neužtenka 60 sekundžių, kad parašytumėte paprastą 5 linijų vieneto testą? Šios 5 kodų eilutės bus rodomos kiekvieną naktį (tai darysite naktį, teisingai?) Kitiems metams ar daugiau ir bus verta pastangų, net jei vieną dieną ji sugautų problemą, kuri galėjo užtrukti 15 minučių ar ilgiau nustatyti ir derinti. Be to, rašant paprastus vieneto testus, vienetų testų skaičius didėja, todėl kūrėjas atrodo gerai.

    • Kita vertus, jei kūrėjas teigia, kad metodas yra pernelyg sudėtingas vieneto testui (ne verta daug pastangų), galbūt tai yra geras požymis, kad metodas turi būti suskirstytas arba pertvarkytas, kad būtų išbandytos lengvos dalys. Paprastai tai yra metodai, kurie remiasi neįprastais ištekliais, tokiais kaip vienkartinis, dabartinis laikas arba išoriniai ištekliai, pvz., Duomenų bazės rezultatų rinkinys. Šie metodai paprastai turi būti pertvarkyti į metodą, kuris gauna išteklius (pvz., GetTime () skambučius) ir metodą, kuris priima šaltinį kaip argumentą (pavyzdžiui, laiko laiko žymę kaip parametrą). Leiskite jiems praleisti bandymo metodą, kuris gauna išteklį, ir vietoj to parašykite vieneto testą metodui, kuris dabar priima šaltinį kaip argumentą. Tai paprastai daro daug paprastesnį rašymo vieneto testą ir todėl verta rašyti.

  • Kūrėjas turi atkreipti „smėlio liniją“ į tai, kiek išsamūs bus jų vieneto testai. Vėliau vystymosi metu, kai mes surasime klaidą, jie turi nustatyti, ar problemos išspręstų išsamesnius vieneto testus. Tokiu atveju, ir jei tokios klaidos atsiranda daugiau nei vieną kartą, jos turi „perkelti“ liniją į išsamesnius vieneto testus ateityje (pradedant nuo dabartinės klaidos vieneto testo pridėjimo arba išplėtimo). Jie turi rasti tinkamą pusiausvyrą.

Svarbu suprasti, kad vieneto testai nėra sidabro kulka, ir yra toks dalykas, kaip per daug vienetų testų. Mano darbovietėje, kai atliekame savo namų darbus, neišvengiamai girdžiu „mums reikia parašyti daugiau vienetų testų“. Vadovybė susitaria dėl to, kad jis buvo nukreiptas į galvą „vieneto testais“ == „geras“.

Tačiau turime suprasti „papildomų vieneto testų“ poveikį. Kūrėjas gali rašyti ~ N eilutes kodo per savaitę, ir jums reikia išsiaiškinti, koks procentas šio kodo turėtų būti vieneto testo kodas ir gamybos kodas. Lengvoje darbo vietoje gali būti 10% kodo vienetų testų ir 90% kodo kaip gamybos kodas, o tai reiškia, kad produktas pasižymi daugeliu (nors ir labai bugiškų) funkcijų (manau, MS Word). Kita vertus, griežtas žurnalas su 90% moduliniu testavimu ir 10% gamybos kodu turės kietojo kūno produktą su labai nedaug funkcijų (manau, „vi“). Jūs niekada negirdėsite apie naujausius produkto gedimus, tačiau tai greičiausiai yra susijusi su tuo, kad produktas nėra labai gerai parduodamas, nes jis susijęs su kodo kokybe.

Dar blogiau, galbūt vienintelis programinės įrangos kūrimo tikrumas yra tas, kad „pokyčiai yra neišvengiami“. Tarkime, kad griežta parduotuvė (90% vienetų testų / gamybos kodų yra 10%) sukuria produktą, kuriame yra tiksliai 2 funkcijos (su sąlyga, kad 5% gamybos kodo == 1). Jei klientas įsijungia ir keičia vieną iš funkcijų, šis pakeitimas sunaikina 50% kodo (45% vienetų testų ir 5% gamybos kodo). Laisvoje parduotuvėje (10% vienetų bandymų / 90% produkto kodo) yra produktas su 18 funkcijų, kurių nė vienas neveikia labai gerai. Jų klientas visiškai atnaujina savo 4 funkcijų reikalavimus. Nepaisant to, kad šis pakeitimas yra 4 kartus didesnis, tik pusė kodo bazės prarandama (~ 25% = ~ 4,4% vienetų testų + 20% gamybos kodo).

Noriu pasakyti, kad jums reikia pranešti, kad suprantate, jog yra pusiausvyra tarp per mažo ir per daug vienetų testavimo - iš tikrųjų jūs galvojote per abi problemos puses. Jei galite įtikinti savo bendraamžius ir (arba) jūsų valdymą, jūs įgysite pasitikėjimą ir, jei įmanoma, gausite daugiau galimybių laimėti.

69
16 сент. Atsakymas pateikiamas Bert F rugsėjo 16 d 2008-09-16 10:02 '08 ne 10:02 2008-09-16 10:02

Daug kartų grojau su vieneto testavimu, ir aš vis dar turiu būti tikras, kad verta mano pastangų, atsižvelgiant į mano situaciją.

Kuriu svetaines, kuriose dauguma logikos apima duomenų bazės duomenų kūrimą, priėmimą ar atnaujinimą. Kai bandžiau „paslėpti“ matavimo vieneto testavimo duomenų bazę, tai buvo labai paini ir atrodė šiek tiek beprasmiška.

Kai parašiau vieneto testus apie verslo logiką, ji niekada man nepadėjo. Kadangi dažniausiai dirbau tik projektuose, paprastai intuityviai žinau, kokias kodo sritis veikia tai, ką dirbau, ir šias sritis tikrinu rankiniu būdu. Noriu kuo greičiau pristatyti sprendimą savo klientui, o vieneto testavimas dažnai atrodo kaip laiko švaistymas. Aš išvardijau rankų testus ir juos perkeliu pačiam.

Matau, kad tai gali būti naudinga, kai kūrimo komanda dirba su projektu ir atnaujina kiekvieną kitą kodą, bet net ir tada manau, kad jei kūrėjai yra aukštos kokybės, dažnai pakanka gero bendravimo ir gerai parašyto kodo.

38
08 июля '09 в 14:19 2009-07-08 14:19 atsakymą pateikė Ronnie liepos 08 d., 09:19, 2009-07-08 14:19

Vienas dalykas, susijęs su vieneto testais, yra tai, kad jie pateikia dokumentus, kaip jūsų kodas turėtų veikti. Geri testai yra panašūs į rekomendacijas, o komandos nariai gali pažvelgti į juos, kad sužinotų, kaip integruoti savo kodą su tavimi.

31
16 сент. atsakymas duodamas užkrečiant rugsėjo 16 d 2008-09-16 00:46 '08, 12:46, 2008-09-16 00:46

Vieno bandymo vertė yra pradinė investicija. Kadangi prieš porą metų pradėjote naudoti vieneto testavimą, aš radau realių privalumų:

  • regresijos tyrimas pašalina baimę daryti kodo pakeitimus (niekas panašus į šiltą matymo kodo švytėjimą ar sprogimą kiekvieną kartą, kai atliekamas pakeitimas)
  • vykdomųjų kodų pavyzdžiai kitiems komandos nariams (ir šešiems mėnesiams ..)
  • negailestingas refaktoravimas yra neįtikėtinai naudingas, išbandykite!

Kodo fragmentai gali padėti sumažinti bandomojo kūrinio pridėtinę vertę. Paprasta sukurti fragmentus, kurie leidžia jums sukurti klasių ir susijusių bandymų įrenginių kontūrus per kelias sekundes.

26
16 сент. Atsakyti Jonathan Webb rugsėjo 16 d 2008-09-16 01:15 '08, 1:15 val. 2008-09-16 01:15

Turėtumėte kuo mažiau patikrinti!

jūs turite parašyti pakankamai atskirų testų, kad atskleistumėte ketinimą. Tai dažnai paslėpta. Testavimo moduliai jums reikalauja. Jei atliksite pakeitimus ir turėsite keisti testus, jums bus mažiau judrus. Laikykite blokų testus trumpus ir saldus. Tada jie yra labai vertingi.

Pernelyg dažnai matau daug testų, kurie niekada nebus pertraukiami, dideli ir neveiksmingi ir nesuteikia didelės vertės, jie tiesiog sulėtina jus.

25
16 сент. Keith Nicholas atsakymas, pateiktas rugsėjo 16 d. 2008-09-16 02:32 '08 at 2:32 am 2008-09-16 02:32

Aš nemačiau to nė viename iš kitų atsakymų, bet pastebėjau, kad galėčiau daug greičiau ištaisyti . Jums nereikia eiti per savo paraišką, naudodami teisingą veiksmų seką, kad gautumėte teisingą kodą, tik norėdami sužinoti, kad padarėte loginę klaidą, ir jūs turite tai padaryti dar kartą. С помощью unit test вы можете просто перейти непосредственно в код, который вы отлаживаете.

23
ответ дан John MacIntyre 10 февр. '09 в 3:21 2009-02-10 03:21