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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Орчуулгыг бүтэн эхээр нь та 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

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

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

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

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

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

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

Mocks болон Stubs объектуудын ялгаа

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

Анх эдгээр ойлголтууд гарч ирэхэд, олон хүмүүс дууриамал объектыг энгийн тестийн ухагдахуун болох stubs-тай хольж хутган, төөрөлдөж байсан. Түүнээс хойш хүмүүс тэдгээрийн ялгааг илүү ойлгосон байх. Хэдийгээр тиймч, хүмүүсийн хэрхэн mock -ыг ашигладгийг мэдэхийн тулд моск болон бусад тест doubles-уудыг мэдэх нь чухал (“doubles” ? хэрэв энэ таньд шинэ ойлголт бол санаа зоволтгүй, хэдхэн мөрийн дараа бүгд ойлгомжтой болно).

Програмын зөвхөн нэг элемент дээр тухайн агшинд санаагаа сайн төвлөрүүлэн та тест хийж байгаа бол энэ бол олны хэлдгээр unit testing юм. Асуудал нь юу вэ гэхлээр таньд ганц нэгжийг (unit) -ыг тестлэхийн тулд ихэвчлэн бусад нэгжүүд шаардлагатай болдог – бидний дээрх жишээн дээр warehouse хэрэг болсон шиг.

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

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

Mocks Aren’t Stubs (орчуулга)

Агуулга:

  • Ердийн тестүүд
  • Дууриамал объектуудтай тестүүд
    • EasyMock ашиглах
  • Дууриамал объектууд (Mock) болон (Stubs) хэлтэрхий объектуудын ялгаа
  • Сонгодог болон дууриамал тестийн загвар
  • Ялгаануудын дундаас сонгох
    • TDD -р хөтлөгдөх
    • Тестийн өгөгдлийг тодорхойлох
    • Тестийн тусгаарлалт
    • Тестээ хэрэгжүүлэлтэйгээ холбох
    • Загварчлалын төрөл
  • Тэгэхээр би сонгодог уу эсвэл дууриамал аргаар тестлэгч үү
  • Төгсгөлийн бодлууд

 

“Дууриамал объект” гэж жинхэнэ объектуудыг тестлэхийн тулд ашигладаг тусгай оъектуудыг нэрлэдэг бөгөөд нилээдгүй дэлгэрсэн нэршил юм. Ихэнх програмчлалын хэлний орчингууд одоо дууриамал объектуудыг хялбар үүсгэж болох өөр өөрсдийн гэсэн тогтолцоотой болцгоосон. Гэв ихэвчлэн хангалттай ойлгомжтой байдаггүй нэг зүйл нь юу вэ гэхлээр хэдийгээр дууриамал объект нь тестлэх зорилгоор ашиглагддаг нэг хэлбэрийн тусгай объект боловч, мөн нөгөөтэйгүүр тестлэх өөр нэг загварчлалын аргыг бий болгосон байдаг. Энэхүү нийтлэлээр би та бүхэнд дууриамал объект хэрхэн ашиглагддаг, үйлдэл шалгах явцыг (behavior verification) хэрхэн дэмждэг болон мөн хөгжүүлж, дэмжиж буй бүлгэмийн залуус хэрхэн өөр нэг тестлэх загварыг хөгжүүлж байгаа талаар тайлбарлах болно.

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

Бүтээгдэхүүнээ бид яагаад тестлэх шаардлагатай вэ ?

Яагаад тестлэх шаардлагагүй вэ ?

  • Хэрэглэгч байхгүй
  • Дээд зэргийн чадварлаг мэргэжлийн ажилчидтай (суперменүүдтэй) тул тестлэх шаардлагагүй
  • Маш богино хугацааны дахин шинэчлэгдэх, нэмэлт өөрчлөлтүүд ордоггүй, нэг л хийгдсэн бол дахин шинэчлэх шаардлагагүй
  • Тетслэх боломжгүй
  • Тестлэх үнэ нь бүтээгдэхүүний үнээс илүү
  • Өмнө нь хэзээ ч алдаа, гомдол гарч байгаагүй, хэрэглэгчээс гомдол ирдэггүй

 

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

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