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

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

Advertisements

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

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

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

 

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

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

Өмнөх үг

Өнөөдөр 2010 оны 1-р сарын 15-ны өдөр. Сайхан нар гийсэн өдөр байлаа.

Дараа дараагийн бичлэгүүдээрээ  Practical Symfony номын 24 хичээлийн эхний хичэлийг орчуулан тавих болно.
Энэхүү ном нь PHP Symfony Framework анхлан сурахад зориулагдсан өдөр бүрийн хичээлийг багтаасан.

Энэхүү номыг уншиж дуусгаснаар symfony Framework талаар суурь мэдлэгтэй болох бөгөөд цаашид хөгжихэд ихээхэн тустай болов уу,

Энэ хуудсанд орчуулгын талаар санал хүсэлтийг авна.  Орчуулах ажил маань миний сонирхлын дагуу хийгдэж байгаа ба ямар хурдтай хийгдэхийг би таашгүй.  Бусад хүмүүс ч бас энэхүү ажилд оролцоно гэдэгт найдаж байна.

Have  fun!