Лекц 11 Ц.Амарбат Unit test

Presentasjon om: "Лекц 11 Ц.Амарбат Unit test"— Utskrift av presentasjonen:

1 Лекц 11 Ц.Амарбат Unit test
Java Programming Лекц 11 Ц.Амарбат Unit test

2 Агуулга Жишээ JUnit тест гэж юу вэ? JUnit тест хэрэгтэй юу?
Асертууд Suite хэрэглэх, тестүүдийг нэгтгэх Тестийн тохиргоо Custom asserts JUnit ба Exception pendingTest… ойлголт

3 Once upon a time… Эртээ урьдын цагт...
Нэгэн компанид Цэцгээ, Нараа хоёр програмист байжээ. Нэг удаа тэр хоёр нэгэн төсөлд оролцон хоёулаа 12 сарын 1-нд үр дүнгээ шалгуулаад бусадтайгаа кодоо нийлүүлэх ёстой болов. Нараа маш хурдтай бичиж байлаа, класс классаар нь угсруулан гаргаж байн байн debugger хэрэглэн болохгүй байгаа алдаагууд нь зассаар яг цагтаа дуусав. Гэвч яг шалгуултал хамгийн үндсэн хэсэг нь үр дүн гаргалгүй алга болчихов. Нараа ийм байх ёсгүй гэж гайхан үзсээр алдааг олов. Гэвч нэмэргүй алдаанууд янз янзаар ажиллуулах тусам гарсаар байлаа. Цэцгээ харин удаанаар ахиж байв. Тэрээр нэг функц бичих болгоныхоо дараа түүний зөв ажиллахад үл итгэн уг функцийг тестлэх дахин нэг код бичиж шалгаж явж байлаа. Тестийн кодыг бичихэд илүү удаан, илүү бодуулж байсан боловч Цэцгээ бууж өгсөнгүй. Тэгээд цагтаа кодоо дуусгаж амжсангүй. Гэхдээ шалгуулахад Цэцгээгийн хийсэн кодууд бараг төгс ажилласан бөгөөд ганц жижиг асуудал гарсан боловч Цэцгээ түүнийг дор нь олж засав. Цэцгээгийн кодыг бусад програмистуудын кодтой нийлүүлэхэд тун зохицтой ажиллаж байлаа.

4 JUnit test Цэцгээ Нараа хоёр хоёулаа ижил ажлын туршлагатай, ижилхэн сэтгэлгээний чадвартай боловч Цэцгээ өөрөөсөө илүү Unit test аргад итгэдэг байв. Цэцгээ код бичих явцад debugger бараг хэрэглэдэггүй нь ч үүнтэй холбоотой байв. Харин Нараа бичсэн кодоо юу хийхийг нь үргэлж “мэддэг” гэж боддог нь түүнийг асуудалд оруулдаг байна. Төслийн эцэст тэрээр мөнхийн debugger-чин болж хувиран юу болоод байгааг ойлгохыг оролдон удаан цагаар суудаг юмаа.

5 JUnit test гэж юу вэ? Төслийн амжилттай болох эсэх нь хэдэн зүйлээс хамаардаг: CVS JUnit testing Ant build system Програмыг бичиж дуусах дөхөх тусамд түүнийг тестлэхэд улам хүнд болж ирдэг. Улам их хугацаа авах болдог. Үүний оронд програмыг бичиж байх явцдаа програмистууд өөрсдөө тестлэн үр дүнг зөв гарч буйд итгэлтэй явбал төгсгөлийн тест маш хялбар хурдан болно. Энэ зорилгоор програмын жижиг дэд хэсгийг үйл ажиллагааг тестлэх тусгай код бичиж өгдөг болсон. Unit test нь програмистын бичиж өгсөн хэсэг код бөгөөд энэ код нь програмын өөр нэг хэсэг жижиг кодыг (функц) хийх ёстой зүйлээ үнэхээр хийж чадаж байгаа эсэхийг шалгах зориулалттай байдаг.

6 JUnit test –г яагаад хэрэглэх ёстой вэ?
Давуу талууд: Debug хийх цагийг эрс бууруулж өгдөг. Зөвхөн чиний ч биш төслийн бусад програмистуудын ажлыг эрс хөнгөвчилж өгнө. Хэрэв доод төвшний кодууд найдваргүй бол түүн дээр тулгуурлан бичигдсэн дээд төвшний кодуудаас тогтсон үндсэн програм найдваргүй болно. Доод төвшний кодын алдааг засахад дээд төвшнийхийг нь мөн өөрчлөх хэрэгтэй болно. Түүнийг нь засахад мөн өөр нэг доод төвшний кодтой тохирохоо болино. Ингэсээр нийт төсөл унахад хүрдэг. Тиймээс төслийн кодыг доод төвшний энгийн хэсгээс нь эхлэн найдвартайгаар бичих хэрэгтэй.

7 JUnit test JUnit test нь чиний өгсөн олон төрлийн өгөгдлийг шалгаж буй кодонд дамжуулан үр дүнг нь гаргаж өгнө. Багийн бусад гишүүд ч уг өгөгдөл болон үр дүнг нь хараад уг кодыг яаж ажиллах талаар илүү ойлголттой болж авдаг. Багийн аль нэг гишүүн тест кодонд магадгүй чиний санаанд ороогүй байдлаар жишээ өгөгдөл өгч шалгагдаж буй кодыг буруу ажиллаж буйг илрүүлж ч болно. Кодыг зөвхөн нэг удаа биш үргэлж зөв ажиллаж буй эсэхийг нь шалгах ёстой байдаг. Бүх тохиолдолд ажиллаж буй програмыг л болж байна гэж үзнэ.

8 JUnit test хэрхэн бичих вэ?
Ер нь бол ямар нэг функцийг бичихээс өмнө хэрхэн тестлэх тухай бодох хэрэгтэй. Ихэнхдээ уг функцтэйгээ зэрэг эсвэл, бичихээс нь өмнө эхлээд тестлэх кодыг бичдэг. Тестлэгч код болон тестлүүлэх код хоёр дууссаны дараа тестийг ажиллуулж үзнэ. Гэхдээ системийн бүх л тестлэгч кодыг ажиллуулах хэрэгтэй. Учир нь энэ нь системийн бусад хэсэг энэ кодтой зохицож буй эсэхийг илрүүлж өгнө. Бүх тест амжилттай гэсэн үзүүүлэлт гарч байвал болж байна гэсэн үг.

9 JUnit test хэрэгтэй юу? Одоо ч гэсэн зарим програмистууд энэ аргыг хэрэггүй гэж үзсээр байдаг. Тэдний хэлдэг гол тайлбаруудыг авч үзье: Тестүүдийг бичихэд хэтэрхий их цаг авдаг. Хариулт: Хэрэв эдгээр тестүүдийг бичихгүй бол төслийн эцэст системийн тестчлэлийг хийхэд бүүр их цаг авдаг. Магадгүй дахин эхнээс нь бичих эсвэл төсөл нурахад ч хүрдэг. Unit тест хэрэглэсэн төсөл Хэрэглээгүй төсөл

10 JUnit test хэрэгтэй юу? Эдгээр тестүүдийг ажиллуулахад хэтэрхий их цаг авдаг. Хариулт: Ингэх ёсгүй. Ихэнх тестүүд асар хурдтай ажилладаг. Тиймээс хэдэн зуу эсвэл мянга мянган ийм тестүүдийг хэдхэн секундэд ажиллуулах боломжтой. Гэхдээ зарим тестүүд үнэхээр удаан ажиллаад байгаа тохиолдол гарвал эдгээр тестүүдийг хурдтай тестүүдээс салгах хэрэгтэй. Тэгээд удаануудыг нь өдөрт эсвэл хэдэн өдөрт нэг удаа ажиллуулж хурднуудыг нь тогтмол ажиллуулж байх хэрэгтэй. Тестлэх нь миний ажил биш. Хариулт : Програмист хүний ажил бол зөв ажилладаг код хийх явдал юм. Ямар нэг тестлэх багт ажиллах үгүй нь мэдэгдэхгүй код өгөөд өөрсдийн хийсэн хогуудыг бусдаар цэвэрлүүлэхийг шаардах нь тэдний ажил бишээ.

11 JUnit test хэрэгтэй юу? Энэ код яг яаж ажиллах талаар би сайн мэдэхгүй байгаа болохоор тестийг нь ч бичиж чадахгүй байна. Хариулт : Хэрвээ яаж ажиллахыг нь мэдэхгүй бол тэр зөв ажиллаж байгаа эсэхийг нь ер нь яаж шалгах юм бэ? Би тестийн багийнхныг ажилгүй болгочихоос өрөвддөг. Хариулт : Санаа зоволтгүй бидний хийж буй энэ тест бол хамгийн доод төвшний програмистуудад зориулсан л тест юм. Системийн араг ясын тест ч гэж болох юм. Тестийн багийнханд өөр зөндөө ажил бий: Жишээ нь : үйл ажиллагааны тест (functional test) хүлээн авалтын тест (acceptance test) Хурдны тест (performance test) Орчны тест (environmental test) Validation, verification, formal analysys болон бусад ажлууд...

12 JUnit test бичиж үзэцгээе.
JUnit тест код бичихдээ жижиг assert хэмээх функцүүдийг хэрэглэдэг. Энэ функц нь хоёр тоог тэнцүү эсэх, ямар нэг нөхцөл биелж буй эсэх зэргийг шалгадаг энгийн функцүүд юм. Жишээ нь : Нөхцөл биелэлтийг шалгах assert нь : Хоёр тоог тэнцүү эсэхийг шалгагч assert нь :

13 JUnit test бичиж үзэцгээе.
Хэрхэн тест код бичих талаар санаа авахын тулд эхний жишээгээ хийж үзье. Бүхэл тоон массиваас хамгийн их тоог нь олдог Largest гэсэн класс хийж үзье. Энэ классын дотор үндсэн үүргийг нь гүйцэтгэх largest гэсэн статик функц байна. Дараа нь тест класс бичин уг классыг ажлаа зөв хийж буй эсэхийг шалгана.

14 JUnit test бичиж үзэцгээе.
Одоо Eclipse дээр шинээр JUnit үүсгэнэ: TestLargest гэсэн нэр өгье.

15 JUnit test бичиж үзэцгээе.
Дараах кодыг бичиж өгье: Үүнийг ажиллуулахад дараах алдаа гарч ирж байна :

16 JUnit test бичиж үзэцгээе.
Тэгэхээр max = Integer.MAX_VALUE; гэж тавьсан байсан маань буруу болсон байна. Үүнийг max = 0 ; болгон өөрчилье. Дахин тестээ ажиллуулж үзнэ. Энэ удаа алдаагүй ажилласныг харуулж байна. Одоо тестээ улам сайжруулъя. Өгч буй тоонуудыг дараалал нь ондоо байвал яах вэ? Дараах кодыг нэмээд дахин ажиллуулна.

17 JUnit test бичиж үзэцгээе.
Дараах кодыг нэмээд дахин ажиллуулна. Эхний тест (testSimple) ок болж хоёрдах тест (testOrder) дээр амжилтгүй утга буцаасныг дараах зурагнаас харж болно:

18 JUnit test бичиж үзэцгээе.

19 JUnit test бичиж үзэцгээе.
For давталт дутуу гүйснээс массивын төгсгөлд байсан 9-г олж чадаагүй бололтой. Кодыг харвал : Үүнийг дараах хоёрын аль нэгээр засаж болно : Үүний дараа тестээ ажиллуулбал амжилттай болсон мэдээлэл гарч байна. Тест дээрээ дахин нэг мөр нэмж үзье :

20 JUnit test бичиж үзэцгээе.
Тест дээрээ дахин нэг мөр нэмж үзье : Одоо тестээ ажиллуулбал дараах алдаа гарна : Энэ нь хамгийн сүүлд max = 0; болгож өөрчилсөнтэй холбоотой.

21 JUnit test бичиж үзэцгээе.
Энэ нь хамгийн сүүлд max = 0; болгож өөрчилсөнтэй холбоотой. Үүнийг max = Integer.MIN_VALUE; болгож өөрчлөх хэрэгтэй байсан байна.

22 JUnit test бичиж үзэцгээе.
Хэрвээ массиваар хоосон массив ороод ирвэл яах вэ? Тэгвэл бид хоосон эсэхийг нь шалгаад хоосон байвал RuntimeException үүсгэдэг болгож кодоо сайжруулъя. Одоо хоосон массив оруулахад болж буй эсэхийг тестээрээ яаж шалгах вэ?

23 JUnit test бичиж үзэцгээе.
Үүний тулд дараах кодыг нэмж өгнө :

24 JUnit test бичиж үзэцгээе.
Одоо манай код гурван тестийг гурвууланг нь давсан байна : JUnit тестийн давуу тал нь дараа нь энэ функцийн кодыг улам сайжруулан эсвэл хэн нэг нь өөрчилчихөж болно. Тэгвэл энэ тестээ нэг ажиллуулаад л дор нь мэдэх боломжтой юм. Ингэхээр динамик өөрчлөгдөн буй системийг бүх үед нь шалган алдааг нь олох боломжтой болдог.

25 JUnit naming convention
Одоо тест кодыг бичихэд анхаарах хэдэн зүйлсийг авч үзье: Хэрэв createAccount( ) функцийг тестлэх код бичиж байгаа бол testCreateAccount гэсэн JUnit үүсгэх хэрэгтэй. Ингэх албагүй боловч ингэж стандарт гаргаснаар үл ойлголцох асуудлыг багасгана. Мэдээж testCreateAccount нь дотроо уг createAccount –г шалгах олон функцүүдтэй байж болно. Тест функц нь дараах шаардлагуудыг хангах ёстой : Шалгагдаж буй кодод шаардлагатай бүх нөөцийг үүсгэх (обьектуудыг үүсгэх, шаардлагатай санах ойг бэлтгэх...) Шалгах функцээ дуудах Уг функц зохих ёсоор ажиллаж буй эсэхийг шалгах Дараа нь өөрийгөө цэвэрлэх

26 Asserts JUnit-д хэрэглэгддэг функцүүдийг үйл ажиллагаагаа зөв явуулж буй эсэхийг шалгадаг функцүүдийг assert-үүд гэж нэрлэдэг. Бид өмнө нь хоёр assert ашигласан: assertEquals( ) assertTrue( ) Assert-үүд нь ажиллан уг нөхцөл биелсэн эсэх, эсвэл санамсаргүй exception үүсгэсэн эсэхийг JUnit-р дамжуулан мэдэгддэг. Хэрэв дээрх нөхцөл байдал үүссэн бол уг тест функц ажиллагаагаа зогсоох боловч бусад нь ажиллах болно. Одоо түгээмэл хэрэглэгддэг assert-үүдийг авч үзье :

27 Asserts assertEquals:
Хамгийн түгээмэл хэрэглэгддэг. Хоёр утгыг тэнцүү эсэхийг шалгана. Expected утгыг actual утгатай тэнцүү байвал true үгүй бол false (буюу failure) утга буцаадаг. False утга буцаасан бол нэмэлт тайлбар мэдээллийг message аргумент ашиглан мэдээлж болно. Харьцуулж буй өгөгдлийн төрлөөс хамааран энэ функцийн өөр өөр төрлийн аргументтай хувилбарууд байдаг. Түүнээс тохирохыг нь хэрэглэхээ санаж байх хэрэгтэй.

28 Asserts assertEquals:
Компьютер нь бутархай тоог хэзээ ч төгс бүрэн дүрсэлж чаддаггүй тул (3, ) энэ тохиолдолд таслалаас хойш хэдэн орон дотор тэнцүү байвал тэнцүү гэж үзэхийг tolerance аргументаар дамжуулан зааж өгдөг. Ихэнх програмуудад tolerance нь 4-5 байхад хангалттай бол шинжлэх ухааны төрлийн програмуудад илүү өндөр хэмжээ шаардлагатай байж болно. Жишээ нь дараах кодонд эхний хоёр оронг л шалгана:

29 Asserts assertNull: assertSame: assertTrue:
Өгөгдсөн обьектийг null эсвэл null биш эсэхийг шалгах асертууд. assertSame: expected, actual хоёр обьектийг нэг обьект (ижил) эсвэл ижил биш эсэхийг шалгана. assertTrue: Өгөгдсөн нөхцлийг үнэн эсэхийг шалгана.

30 Asserts fail: Өгөгдсөн мэдээллийг үзүүлээд тестийн кодыг зогсооно. Ихэвчлэн тестийн кодыг цааш нь ажиллуулах шаардлаггүй гэсэн үед (жишээ нь exception үүсвэл) хэрэглэнэ. Эдгээр бүх асертууд TestCase класс дотор байдаг. Тиймээс JUnit нь энэ классаас удамшсан байдаг. Энэ класс дотор байх test… нэртэй бүх функцүүд автоматаар дуудагддаг.

31 Suite функц ашиглах Тест класс нь мөн өөрөө бусад тест классуудыг эсвэл бүхэл системээр нь дуудаж чадна. Үүнийг suite ашиглан гүйцэтгэнэ. Жишээ болгон хоёр тест кодыг авч үзье. Эхнийх нь нэлээд энгийн :

32 Suite функц ашиглах Хоёрдах тест нь “нэг хотоос нөгөө хот хүрэх хамгийн дөт замыг олох” бодлогыг шийдсэн алгоритмыг шалгадаг байг. Энэ алгоритм нь бага тооны хотууд дээр хурдан ажилладаг боловч хэдэн зуун хотуудын хувьд 20,000 жил ч ажиллаж магадгүй. Тиймээс их тооны хотуудын хувьд үргэлж ажиллуулаад байх нь хэцүү болно. Бид олон тооны хотуудын хувьд хааяа л ажиллуулж цөөн тооны хотуудын хувьд үргэлж ажиллуулж байхаар хийх хэрэгтэй. Энэ бодлогыг шийддэг класс нь TSP (Travel Sales Person) байг. Тэгвэл энэ классыг шалгах тест код нь дараах байдалтай байж болно:

33 Suite

34 Suite функц ашиглах Энэ тохиолдолд зөвхөн suite функц л дуудагдан түүнд заагдсан байгаа тестүүд л ажиллах болно. Suite-г ийм зарчмаар ашиглан богино хугацаанд ажиллах тестүүдийг үргэлж ажилладаг болгох юм. Тест классыг үүсгэхэд байгуулагч функц нь String аргумент авч байсан. Одоо энэ аргументийн зорилго тодорхой болж байна. Энэ аргументаар тестийн аль функцийг дуудвал зохихыг дамжуулж өгч байна. Өмнөх кодонд бид хоёр хурдан ажиллах тестийг ажиллуулахыг зааж өгсөн байгаа. Одоо дахин нэг тест класс үүсгэн өмнө бичигдсэн байгаа хоёр тестийг дуудаж ажиллуулдаг болгоё:

35 Suite функц ашиглах Одоо TestClassComposite классыг ажиллуулбал дараах функцүүд ажиллана : TestClassOne классын testAddition( ) TestClassTwo классын testShortestTest( ) TestClassTwo классын testAnotherShortTest( )

36 Тестийн тохиргоо Хэрэв тест функцүүдийн өмнө нь ямар нэг тохиргоо хийгдээд (жишээ нь өгөгдлийн сантай холбох) ажиллаж дууссаных нь дараа бас нэг тохиргоо хийгдэх (холбоог салгах) ёстой байвал яах вэ? Иймэрхүү ижил тест функц бүрт дээрх тохиргоог хийж өгөх бол бичих код их болж ирнэ. TestCase класс дотор дараах хоёр функц байдаг: setUp( ) : Тест функц бүрийн өмнө автоматаар дуудагдана. tearDown( ) : Тест функц бүрийн дараа автоматаар дуудагдана. Энэ хоёр функцийг дахин тодорхойлж өгснөөр дээрх тохиолдолд ажиллах боломжтой болно.

37 Тестийн тохиргоо Жишээ авч үзье:

38 Тестийн тохиргоо setUp( ) функц нь testAccountAccess( ), testEmployeeAccess( ) хоёр функцийн өмнө автоматаар дуудагдан өгөгдлийн сантай нь холбож өгнө. tearDown( ) функц нь testAccountAccess( ), testEmployeeAccess( ) хоёр функцийг ажиллаж дууссаны дараа автоматаар дуудагдан өгөгдлийн сангаас холбоог нь салгаж өгнө. Suite ашиглан олон тестүүдийг шилж нэгтгэн нэг дор ажиллуулж болж байсан. Хэрэв эдгээр тестүүдийн өмнө нэг тохиргоо хийгдэн бүгдийг нь ажиллаж дууссаны дараа бас нэг тохиргоо хийгдэх бол яах вэ? Өмнө нь бид функц бүрийн өмнө болон дараа хийгдэх тохиргоог ярисан. Одоо бүхэл нэгдмэл тестийн өмнө болон дараа хийгдэх тохиргоог авч үзэх хэрэгтэй.

39 Тестийн тохиргоо Үүний тулд бүлэг тестээ бэлтгээд (suite) үүнийгээ TestSetup классын обьектод оруулж өгөх хэрэгтэй. Үүний дараа TestSetup обьектийн setUp( ), tearDown( ) функцүүдийг хүссэнээрээ дахин тодорхойлон нэгдмэл тестийн тохиргоог хийж өгдөг. TSP тестийн жишээн дээрээ үүнийг харъя:

40 Тестийн тохиргоо

41 Тестийн тохиргоо

42 Custom asserts Ихэнх тохиолдолд TestCase класс доторх асертууд тестүүдийг бичихэд хангалттай байдаг боловч зарим онцгой тохиолдолд өөрийн гэсэн асерттай байх нь зүгээр байх тохиолдол байдаг. Жишээ нь санхүүгийн програм бичиж байгаа тохиолдолд Money гэсэн өгөгдлийн төрлийг байнга шалгах шаардлага гардаг байж болно. Энэ тохиолдолд өөрийн гэсэн асерт хэрэглэхгүй бол нэг ижил төстэй тест кодуудыг байнга бичих хэрэг болдог. Өөрийн гэсэн асерт хийхийн тулд TestCase классаас удамшсан өөрийн гэсэн класс үүсгээд түүндээ нэмэлт асертаа хийж өгнө. Дараа нь бичсэн бүх тестүүдээ энэ классаас удамшуулан ашиглах хэрэгтэй.

43 Custom asserts Жишээ :

44 Custom asserts Одоо тестүүдээ дараах байдлаар бичнэ:
Ер нь өөрийн гэсэн асерт хэрэглэхгүй байсан ч TestCase классаас удамшсан өөрийн гэсэн хоосон классыг хэрэглэж эхлэх нь зүйтэй санаа юм. Ингэснээр хэрэв явцын дунд шинэ асерт хэрэгтэй болбол олон кодонд засвар хийлгүйгээр шууд нэмж өгөх давуу талтай.

45 JUnit & Exception Зарим тохиолдолд функцүүд exception үүсгэх ёстой байдаг. Програмист нь энэхүү үүсгэсэн exception-г дээд төвшний функцээс барьж аван боловсруулах ёстойгоор хийсэн байг. Хэрэв энэ тохиолдолд функц маань exception үүсгэх ёстой үе дээр үүсгэхгүй байвал уг алдаа боловсруулагдахгүй үлдэн програм маань буруу ажиллахад хүрнэ. Тиймээс exception үүсч буй эсэхийг ч тестлэх шаардлага гарч ирдэг. Хэрэв тестээс exception үүсээгүй бол тест маань fail болдоггүй. Гэтэл бид fail гэсэн мэдээлэл авахыг хүсдэг. Энэ тохиолдолд жишээ нь дараах байдлаар бичиж өгч болно :

46 JUnit & Exception Гэхдээ боломжит exception болгон дээр fail функцийг хэрэглэн өөрөө бичсэнээс энэ ажлыг JUnit-д даатгаж болно. Үүнийг дараах байдлаар хийж өгч болно:

47 pendingTest Энэ тохиолдолд харгалзах exception үүсвэл JUnit нь fail үүсгэхийн хамтаар үүссэн exception stack trace –г хамтаар нь өгдөг тул энэ нь програмистад маш чухал мэдээлэл болж өгдөг. Одоо програмын нэг хэсгийг тестийн хамтаар бичээд ок болж гэж үзье. Тэгээд дараачийн кодыг шинэ тестийн хамтаар бичиж эхэлнэ. Шинэ тестүүд нь автоматаар бүгдийг дуудах бүлэг тестэнд бичигдэнэ. Гэтэл тестийг ажиллуулах тоолонд болоогүй байгаа тестүүд ажиллан бөөн алдаа гарч эхэлдэг. Одоохондоо болоогүй байгаа тестүүдийг ажиллуулалгүйгээр өмнөх тестүүд л ажиллаж байхаар яаж хийх вэ?

48 pendingTest Үүнийг шийдэхдээ шинээр бичиж буй тестүүдийг pendingTest… гэсэн нэрээр нэрлэх хэрэгтэй. Энэ тохиолдолд JUnit нь ийм тестүүдийг ажиллуулалгүйгээр бусад тестүүдийг л ажиллуулдаг. Тест бэлэн болсны дараа бид нэрийг нь test… болгон өөрчилж болно. Мөн pendingTest нэртэйгээр хайж дутуу орхисон тестүүдээ хайж олох давуу талтай.