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

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

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

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

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

Advertisements

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

Орчуулгыг бүтэн эхээр нь та 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 (хөрш объекттой харилцах гаралтын интерфэйс) -ыг судлан олдог.

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

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

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

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

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

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

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

Дууриамал (Mock) объектуудтай тестүүд

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

Одоо би дээрхтэй ижил үйлдлүүдтэй боловч дууриамал объекттой тест бичье. Энэ кодонд би jMock санг ашиглан дууриамал объектуудыг тодорхойлно. jMock бол жава хэлний дууриамал объект-ын сан. Хэдийгээр өөр нилээдгүй хэдэн дууриамал объектын сангууд байдаг хэдий ч, энэ сан нь тэрхүү техникийг үүсгэгчдийн өөсрдийх нь бичсэн сан тул анхлан ашиглахад тохиромжтой.

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

DDD гэж юу вэ, хэрхэн ашиглах талаар

DDD гэж юу вэ ?

Domain-driven design гэдэг нь тухайн бизнесийн салбарын хүчин зүйлүүд (бизнест мөнгө авчирч байгаа тэдгээр зүйлүүд) дээр төвлөрч хөгжүүлэлтээ хийх буюу технологи болон бусад зүйлийг хоёрдугаарт тавин бизнесийг дэмжих гэсэн санаа.

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