Төгсгөлийн бодлууд

Орчуулгыг бүтэн эхээр нь та wordpress-ээс болон   gitbook.com  -с  үзэх боломжтой.

Unit testing хийх сонирхол ихсэх тусам xunit тогтолцоонууд (frameworks) болон Тестээр Хөтлөгдөх Хөгжүүлэлт (Test Driven Development) өсөж, улам бүр хүмүүс дуураймал объекттой тестүүд уруу орох хандлагатай байна. Ихэнхдээ хүмүүс дуураймал объектын тогтолцооны (framework) -ийн талаар өнгөцхөн мэдлэгтэй, түүний үндэс суурь болох дуураймал/сонгодог гэж хуваалтын талаар ямар ч ойлголтгүй байдаг. Миний бодлоор та аль ч талд нь (дуураймал болон сонгодог аргуудын) зогсож байлаа ч эдгээр ялгаануудын талаар мэдэж байх нь хэрэгтэй. Та заавал дуураймал аргаар хөгжүүлэгч байж байж л дуураймал тогтолцооны давуу талуудыг мэддэг байх албагүй бөгөөд хөгжүүлэгдэж буй програмын тань загварын олон сонголт, шийдвэрүүд рүү хөтлөх тэдгээр бодлуудыг (thinking) ойлгож байх нь илүү хэрэгтэй.

Энэхүү нийтлэлийн зорилго нь тэдгээр ялгаануудыг онцолж, хоорондын харилцан давуу талуудыг (trade-offs) ялгаж, тодорхой болгох байсан. Миний энэхүү нийтлэлд дурдаагүй өнгөрсөн, загварчлах аргаас бий болдог дуураймал хөгжүүлэлтийн бодлууд (thinking) нэлээдгүй байдаг. Ирэх хэдэн жилд бид үүн дээр илүү анхаарсан мөн кодын өмнө бичигдэх тестээс үүдэлтэй гайхалтай үр дагавруудын талаарх бидний ойлголтыг илүү нэмэгдүүлэх нийтлэлүүдийг илүү харна гэдэгт би итгэж байна.

Нийтлэлийг бүтнээр нь мөн gitbook.com -с унших, татаж авах боломжтой. Холбоос https://www.gitbook.com/book/erheme318/mocks-aren-t-stubs

Нийтлэлийн эх сурвалж:
http://martinfowler.com/articles/mocksArentStubs.html#FinalThoughts

Advertisements

Тэгэхээр би сонгодог уу эсвэл дууриамал тестийн аргаар хөгжүүлэгч үү ?

Орчуулгыг бүтэн эхээр нь та wordpress-ээс болон   gitbook.com  -с  үзэх боломжтой.

Энэ асуултанд итгэлтэйгээр хариулахад хэцүү. Хувьдаа бол би үргэлж хуучинсаг барилтай сонгодог TDD-р хөгжүүлэгч, үүнийгээ өөрчлөх шалтгаануудыг одоо хүртэл олоогүй л байна. Би дууриамал TDD-р хөгжүүлэгчийн үнэнхүү давуу талыг олж харахгүй байгаа ба би тестээ гүйцэтгэлтэйгээ холбохоос гарах үр дагаварыг илүү анхаарч үздэг.

Энэ намайг дууриамал аргаар хөгжүүлэгчийг ажиглаж байхад гайхшруулдаг зүйлүүдийн нэг. Би тестээ бичиж байхдаа үйлдлээ (behavior) хэрхэн хийхээ биш, харин үр дүндээ анхаарч ажиллах дуртай. Дууриамал аргаар хөгжүүлэгч тэгэх байх гэсэн нөхцлүүд (expectations) -ээ бичихийн тулд хэрхэн SUT (System Under Test буюу Тестлэгдэж буй объект) -оо хэрхэн бичих тогтмол талаар бодож байдаг. Би үүнтэй ерөөсөө дасаж өгдөггүй.

Мөн би өөрөө дууриамал TDD-г тоглоомоос илүүтэй өөр зүйл дээр оролдож үзэхгүй байгаадаа зовж явдаг. Миний Тестээр Хөтлөгдөх Хөгжүүлэлт (Test Driven Development) аргаас сурсанчлан, бодит зүйл дээр оролдож үзэлгүйгээр аливаа аргыг (technique-г) шүүмжлэх нь хэцүү. Би дууриамал аргад үнэмшилтэй, түүндээ дуртай олон сайн хөгжүүлэгчдийг мэднэ. Хэдийгээр би өөрөө сонгодог аргад үнэмшилтэй боловч, би хоёр талын давуу, сул талуудыг таньд тунгаан бодох боломжтойгоор өөрийнхөө чадах чинээгээрээ шударгаар хэлж өгч чадна.

Тиймээс хэрэв дууриамал арга таны анхаарлыг татаж байвал би таньд оролдоод үзэхийг санал болгож байна. Ялангуяа хэрэв таньд дууриамал TDD-р сайжруулах боломжтой асуудлууд байгаа бол энэ нь илүү үр дүнтэй байх болов уу. Үүнд би хоёр зүйлийг дурьдаж болж байна. Эхнийх нь хэрэв тест ажиллахгүй (fail) болох болгонд та маш олон цагийг зарцуулдаг бөгөөд шалтгаан нь тест цэвэрхэн fail хийхгүй буюу ажиллахгүй болсон тест таньд хаана алдаа байгаа талаар нарийн хэлэхгүй байгаа бол. (Та үүнийн мөн сонгодог TDD аргаар илүү нарийн тодорхойлогдсон (fine grained) тестүүдийг бий болгож шийдэж болно.) Хоёр дахь нь хэрэв таны объектууд хангалттай үйлдлүүдийг агуулахгүй байгаа бол дууриамал тестийн арга хөгжүүлэгч багыг тань илүү үйлдлүүдээр баян объектуудыг үүсгэхэд тань туслах болно.

 

Нийтлэлийг бүтнээр нь мөн gitbook.com -с унших, татаж авах боломжтой. Холбоос https://www.gitbook.com/book/erheme318/mocks-aren-t-stubs

Нийтлэлийн эх сурвалж:
http://martinfowler.com/articles/mocksArentStubs.html#SoShouldIBeAClassicistOrAMockist

Загварчлалын төрөл

Орчуулгыг бүтэн эхээр нь та wordpress-ээс болон   gitbook.com  -с  үзэх боломжтой.

Эдгээр тестийн аргуудын нэг сонирхолтой зүйл нь миний хувьд тестийн арга хэрхэн загварчлах шийдвэрт нөлөөлдөгт оршдог. Хоёр аргын хөгжүүлэгч нартай уулзаж ярилцсанаар би тухайн аргуудын дэмждэг загварчлалын хоорондын ялгааны талаар тодорхой ойлголттой болсон. Хэдий тийм ч би дөнгөж өнгөц төдий ойлголттой байгаа гэдэгтээ эргэлзэхгүй байна.

Аргуудын ялгааны талаар би дээр давхаргуудад нэвтрэх хэсэгт дурьдсан. Дууриамал тестийн арга **outside-in** аргачлалыг дэмждэг бол **domain model** -г түрүүлж хөгжүүлэхийг илүүд үздэг хөгжүүлэгчид сонгодог аргачлалаар замнадаг.

Үргэлжлүүлэн унших

Тестээ гүйцэтгэлтэйгээ холбох

Орчуулгыг бүтэн эхээр нь та wordpress-ээс болон   gitbook.com  -с  үзэх боломжтой.

Дууриамал тестийн аргаар тест бичихдээ SUT өөрийн хамтрагч объектуудтай зөв харилцаж байгаа эсэхийг нь батлахын тулд түүний *outbound calls* (хөрш объекттой харилцах гаралтын хандалтуудыг) -ыг нь тестлэдэг. Харин сонгодог аргаар бичигдсэн тестүүдэд эцсийн үр дүнг л шалгадаг учир яаж тэнд хүрснийг нь анхаарч авч үздэггүй. Тиймээс дууриамал аргаар хөгжүүлэгдсэн тестүүд методынхоо гүйцэтгэлтэй илүү холбогдсон (coupled) байдаг. Хамтрагчууд (collaborators) руугаа хандах дуудалтыг өөрчилөхөд л дууриамал аргаар бичигдсэн тестыг зогсоож, ажиллахгүй болгодог.

Ингэж холбож (coupling хийж) өгөх нь цаашид анхаарвал зохих хэдэн зүйлүүд рүү хөтөлдөг. Хамгийн чухал нь Тестээр Хөтлөгдөх Хөгжүүлэлт (Test Driven Development)-д гарах өөрчлөлт юм. Дууриамал аргаар бол тест бичих нь таныг гүйцэтгэлийнхээ юу хийх үйлдлүүдийг бодох боломж олгодог. Үүнийг дууриамал аргаар хөгжүүлэгчид давуу тал гэж үздэг. Харин сонгодог аргаар хөгжүүлэгчид зөвхөн гадаад интэрфэйсээс нь юу хийгдэхийг нь анхаарч бодох нь чухал гэж үздэг ба гүйцэтгэлийн бүх нарийн ширийнийг нь тестээ бичиж дуусах хүртлээ анхаарч авч үздэггүй.

Үргэлжлүүлэн унших

Тест тусгаарлалт

Орчуулгыг бүтэн эхээр нь та wordpress-ээс болон   gitbook.com  -с  үзэх боломжтой.

Хэрэв та дууриамал тесттэй хийгдсэн системд ямар нэгэн алдаа хийвэл, зөвхөн алдаатай SUT-ыг агуулсан тестүүд л ажиллахгүй болно. Харин сонгодог аргаар хийгдсэн системд алдаа хийвэл алдаатай объектыг агуулсан бүх тестүүд ажиллахгүй ба үүнд алдаатай объект бусад тестэнд хамтрагчаар орж ашиглагдаж байгаа тестүүд ч мөн орно. Үүнээс үүдээд олон дахин ашиглагдаж буй объектод гарах нэг алдаа нийт системийг хамарсан маш олон алдааг дагуулдаг.

Дууриамал аргаар хөгжүүлэгчид үүнийг маш том дутагдалтай тал гэж үздэг; учир нь алдааны үндсэн шалтгааныг олж, засахын тулд маш олон тооны debug-ын хийх хэрэгтэй болдог. Харин сонгодог аргаар хөгжүүлэгчид үүнийг асуудал гэж үздэггүй. Ихэвчлэн алдаатай кодыг илрүүлэх нь нилээд хялбархан байдаг ба хөгжүүлэгч ажиллахгүй тестийг хараад л аль алдаа хаанаас үүдэлтэйг хэлж чаддаг. Мөн түүнчлэн хэрэв та байнга тестлэдэг бол (хэрэв үгүй бол, та тэгэх хэрэгтэй), гарсан алдаа тань таны хамгийн сүүлд өөрчилсөн кодоос үүсэлтэйг та мэддэг учираас алдааг олоход тийм ч хүндрэлтэй байдаггүй.

Үргэлжлүүлэн унших

Тестийн өгөгдлийг тодорхойлох

Орчуулгыг бүтэн эхээр нь та wordpress-ээс болон   gitbook.com  -с  үзэх боломжтой.

Сонгодог аргаар бол та SUT-ыг тестлэхийн тулд түүнийг хамтрагчуудыг мөн адил үүсгэж өгөх хэрэгтэй болно. Хэдийгээр дээрх жишээнд хэдхэн цөөхөн объектууд ашиглагдаж байгаа боловч жинхэнэ тестэнд олон тооны хамтрагч дэд объектууд шаардлагатай болдог. Ихэвчлэн эдгээр объектууд тест тус бүрт дээр шинээр үүсэж, мөн устгагдаг.

Харин дууриамал тестийн аргаар бол зөвхөн SUT л үүсдэг ба бусад хөрш, хамтрагч объектуудых нь оронд дууриамал объектуудыг ашигладаг. Ингэж илүү нүсэр тестийн өгөгдөл үүсгэхээс зайлхийж болдог. (Ямартай ч ингэж тодорхойлдог. Би нилээд төвөгтэй үүсгэгддэг дууриамал объектын бүтэц, байдалтай таарч байсан ч энэ маань магадгүй tool-үүдийг буруу ашигласнаас байж ч болох юм.)

Үргэлжлүүлэн унших

TDD -р хөтлөгдөх

Орчуулгыг бүтэн эхээр нь та wordpress-ээс болон   gitbook.com  -с  үзэх боломжтой.

Дууриамал объект бол XP -ийн бүлгээс гаралтай ба XP-ын гол онцлогуудын нэг нь Тестээр Хөтлөгдөх Хөгжүүлэлт (Test Driven Development) -ийн аргыг чухалчилдаг билээ. Үүнд системийн загварын хувьсал, өөрчлөлтүүд нь бичигдэх тестээр хөтлөгдөн давталтат (iterative) байдлаар хийгддэг.

Тиймээс дууриамал тестийн аргаар хөгжүүлэгчид тухайн арга системийн загварт хэрхэн нөлөөлдөг талаар тусгайлан авч үздгийг гайхах зүйлгүй юм. Ялангуяа тэд Need-driven development (шаардлагаас хөтлөгдөх хөгжүүлэлт) гэх аргыг зориуд дэмждэг. Энэ аргаар бол та user story (хэрэглэгчийн шаардлага, хэрэглэгдэх байдал) -ыг хөгжүүлэхдээ эхлээд системийн хамгийн гадна талаас нь тестлэх байдлаар эхэлж, SUT (System Under Test)-ынхаа интерфайсыг тодорхойлдог. Хамтрагч объектуудын хийгдэх үйлдлүүдийг нь олохдоо, SUT болон түүний хөрш объектуудыг хоорондын харилцааг судлан SUT-н outbound interface (хөрш объекттой харилцах гаралтын интерфэйс) -ыг судлан олдог.

Үргэлжлүүлэн унших

Ялгаануудаас сонгох

Орчуулгыг бүтэн эхээр нь та wordpress-ээс болон   gitbook.com  -с  үзэх боломжтой.

Энэ нийтлэлд би дараах хос ялгаануудын талаар тайлбарлана: төлвөөр (state) батлах уу эсвэл үйлдлээр батлах уу / сонгодог TDD юу эсвэл дууриамал ТDD юу. Дээрх аргуудын нэгийг сонгохдоо ямар зарчмуудыг баримтлах хэрэгтэй вэ ? Эхлээд үйлдлээр батлахын эсрэг төлвөөр батлах аргыг авч үзье.

Эхний авч үзэх шаардлагатай зүйл нь тухайн нөхцөл байдал (context) юм. Бидний ажиллаж буй объект хоорондын харилцаа (collaboration) *захиалга* (order) болон *агуулах* (warehouse) хоёртой адилхан хялбархан байна уу эсвэл *захиалга* (order) болон *mail service* шиг төвөгтэй байна уу ? гэдэг байгаан.

Хэрэв хоорондын харилцаа нь хялбархан бол сонголт хийхэд амархан. Хэрэв би сонгодог TDD аргаар хөгжүүлэгч бол би ямар нэгэн *дууриамал объект* (*mock*), *stub*, *double*-уудыг ашиглахгүй. Би жинхэнэ объектууд болон төлвөөр батлах аргыг ашиглана. Хэрэв би дууриамал TDD аргаар хөгжүүлэгч бол дууриамал объектууд болон үйлдлээр батлах аргуудыг ашиглана. Шийдвэр гаргахад ямар ч асуудалгүй.

Хэрэв хоорондын харилцаа нь төвөгтэй бөгөөд би дууриамал TDD аргаар хөгжүүлэгч бол би дууриамал объектууд болон үйлдлээр батлах аргыг асуудалгүйгээр авч ашиглана. Харин би сонгодог аргааг хөгжүүлэгч бол надаа сонголт бий. Үүнд альнийг нь сонгох нь мөн тийм ч чухал биш. Ихэвчлэн сонгодог аргаар хөгжүүлэгчид тухайн байдлаасаа болоод аль амрыг нь сонгодог.

Бид төлвөөр эсвэл үйлдлээр батлах сонголтыг хийхэд тийм ч хүндрэлтэй биш гэдгийг харлаа. Гол асуудал нь сонгодог TDD юу эсвэл дууриамал TDD юу гэсэн сонголт юм. Төлвөөр батлах болон үйлдлээр батлах аргуудын зарчмууд энэхүү хэлэлцүүлэгт нөлөөлөх нь зайлшгүй бөгөөд үүнд би онцгой анхаарах болно.

Эхлэхээсээ өмнө би нэг хязгаарын нөхцөлийг дурьдахгүй бол болохгүй нь. Зарим үед объект хооронд харилцаа хялбар байсан ч төлвөөр батлах аргыг ашиглахад нилээд төвөгтэй байдаг. Үүний нэг сонгодог жишээ нь *cache* юм. Гол зүйл нь *cache* -ын тухайн төлвөөс та *cache hit* болсон уу *cache missed* болсныг хэлж чаддаггүй. Энэ нөхцөлд хэдийгээр та үнэнч сонгодог TDD аргыг баримтлагч байсан ч үйлдлээр батлах аргыг сонгосон нь дээр болохыг ойлгоно. Үүнтэй ижил мөн өөр олон төрлийн хязгаарын нөхцлүүд хоёр аргад хоёуланд байгаа гэдэгт би эргэлзэхгүй байна.

Сонгодог уу, эсвэл дууриамал аргаар хөгжүүлэгч үү гэсэн сонголтыг хийхэд бид нилээд хэдэн хүчин зүйлүүдийг авч үзэх шаардлагатай болохоор би дараах байдлаар тойм хэдэн бүлгүүдэд хуваасан болно.

Нийтлэлийг бүтнээр нь мөн gitbook.com -с унших, татаж авах боломжтой. Холбоос https://www.gitbook.com/book/erheme318/mocks-aren-t-stubs

Gitbook рүү шилжсэн нь

Mocks Aren’t Stubs орчуулгынхаа өөртөө болон  уншигчиддаа хялбар болгох үүднээс gitbook.com  руу шилжүүлчлээ. Энэхүү сайт нь номын эхийг git – хувилбар удирдах систем дээр хөтөлдөг бөгөөд markdown форматаар загварчаллыг нь харуулдаг болохоор нэмэлт өөрчлөлт оруулах болон Pdf, Mobi, Epub болон шууд онлайнаар уншихад маш энгийн хялбар болгож өгчээ.

Ер нь би гүүглэ док дээр орчуулгаа хийдэг байсан бөгөөд вордпресс рүү хуулан тавихад формат нь өөрчлөгдөж, жижиг засварууд хийхэд хоёуланд нь зэрэг хийх зэрэг нилээд төвөгтэй байдаг. Харин одоо энэ гитбүүк рүү шилжүүлчихээр тэдгээр хүндрэлүүдээс зайлсхийх боломжтой болсон гэж бодож байна.

Мөн вордпресс эх кодыг харуулахдаа маш муу бөгөөд ерөөсөө syntax highlight -ын буюу кодыг бичигдсэн хэлд нь зориулж өнгөөр харуулдаггүй нь бас нэг том хүндрэл байлаа. Гитбүүк үүнийг мөн шийдчихлээ.

Мөн гитбүүк дээр хамтраад нэг орчуулгыг олон хүн хийх боломжтой болсон. Хэрэв та ямар нэгэн үг, дүрмийн алдаа болон утгын хувьд засчихмаар зүйлийг олж харвал та мөн шууд засах болон надтай хамтран орчуулга хийх боломжтой болсон шүү.

Амжилт!

 

 

Сонгодог болон дууриамал тестийн арга

Орчуулгыг бүтэн эхээр нь та wordpress-ээс болон   gitbook.com  -с  үзэх боломжтой.

Одоо би хоёр дахь ялгаа болох сонгодог болон дууриамал TDD -ийн ялгааны талаар судлах боломжтой боллоо. Гол асуудал маань яг хэзээ дууримал объект (бусад Double)  -уудыг хэрэглэх вэ юм.

Сонгодог TDD -ын загвараар бол болж өгвөл аль болох жинхэнэ объектуудыг ашиглаж харин жинхэнийг ашиглахад төвөгтэй үед double -ыг ашиглахыг зөвлөдөг. Тиймээс сонгодог TDD аргаар хөгжүүлэгчид жинхэнэ агуулах (warehouse) объектыг ашиглаж харин mail service -ын оронд double-ыг ашиглах байсан байх. Харин ямар төрлийн double нь тийм ч  чухал зүйл биш.

Дууриамал TDD загвараар хөгжүүлэгчид харин үргэлж дууриамал объектыг бүх төрлийн элдэвийн үйлдлүүдтэй объектын оронд ашигладаг. Дээрх жишээнд агуулах (warehouse) болон mail service хоёрын хоёулангых нь оронд дууриамал объектыг ашиглах байсан.

Үргэлжлүүлэн унших