Search the Community

Varu padalīties nelielā pieredzē. Vide - phpstorm, git, laravel, pie projekta strādāju viens. Projekts: http://pointsback.lv Projekta neliels aprakts: ir divi useru tipi - pircēji, pārdevēji. Pircējs iepērkas pie pārdevējiem, saņem par to punktus no pārdevēja konta savā. Pircējs var arī tērēt savus punktus. Pamatā vienkāršas punktu transakcijas, viss notiek caur API. Testos esmu galīgs iesācējs, unittestus vēl īsti nemāku rakstīt (kods pārāk līks, lai normāli testētu), bet mēģinu vismaz integrācijas testus rakstīt. Ja kāds nezina, tad integrācijas tests ir, kad testē jau kaut kādas sistēmas daļas kopumā, vai tās funkcionē pareizi, vai tās strādā korekti. Unittesta gadījumā tiek testēta kaut kāda maza vienība, pilnībā izolējot to no ārējiem apstākļiem (datubāzes, modeļiem, api, utt utt). Es parasti uzrakstu kaut kādu funckionalitāti un uzreiz mēģinu uzrakstīt arī pāris testus. Testa gaita ir apmēram šāda - palaižot testu, man katru reizi tiek uzbūvēta jauna datubāze, visas tabulas, tiek ievietoti kaut kādi pamata dati (useru grupas, permisiju tipi, whatever). Tad es uzkodēju kaut kādus scenārijus. Piemēram, 1. Ieskaitam veikala kontā 100 punktus 2. Piereģistrējam lietotāju 3. Pārskaitam no veikala konta 60 punktus 4. Pārbaudam vai lietotājam kontā ir 60 punkti 5. Pārbaudam vai veikalam kontā atlikuši 40 punkti Tādā garā ir arī visi testi. Testi mani izglābuši vairākkārt. Viens spilgs gadījums atmiņā - vajag ieviest nosacījumu, ka pārskaitot no veikala pircējam punktus, tiek ieturēta komisija. Ok, domu gaita sekojoša - papildus kolonna veikalu tabulai ar komisijas %. Attiecīgi, rodas nosacījums, ka tagad veikala konta atlikums ir jāglabā kā decimāla daļa, jo, 50% no 1 punkta ir 0.5 punkti, attiecīgi, pārskaitot no veikala pircējam punktus, veikalam paliek par 1.5 punktiem mazzāk. Turpmākās darbības galvā vienkāršas - pieliekam komisijas kolonnu, pielabojam funkciju kas pārskaita punktus (pieskaita/atņem no veikala konta), lai tiktu atrēķināta komisija. Viss it kā vienkārši, kļūdām nevajadzētu būt - laižu testus, un - kļūda! Nesakrīt summas. Rokos dziļāk, un atrodu vienā metodē, ka palicis - $shop->points = (int)$points; Ahā, notiek decimāldaļas atmešana! Pielabojam uz (float), viss rullē! Šādu kļūdu, es visdrīzāk nebūtu atradis ar roku, ja vien neuztrāpītu uz konkrētā robežgadījuma. Paietu labs laiks, kamēr saprastu, kas noticis un, kur nu vēl savest visu kārtībā - izsekot, kuram veikalam cik tagad ir pazudis, cik jāpieskaita klāt. Karoč, produkcijā viss slikti. Līdzīgi testēju arī API izsaukumus - veicu izsaukumus kontrolierim, padodu derīgus/nederīgus datus, pārbaudu rezultātu, utt utt. API tomēr ir tāda lieta, kas nedrīkst vispār mainīties (vismaz tā pēkšņi), ja to jau produkcijā lieto N cilvēki. Viena kļūda var maksāt dārgi, kaut vai programmētāja laika resursā. Piemēram, vajag API notestēt, vai strādā autorizācija: Šeit apskatāms viss test case priekš API: http://pastebin.com/b6X77uaZ Šādi ~ izskatās punktu došanas tests: Mans secinājums pēc šī projekta noteikti ir tāds, ka vismaz kaut kādus testus vajag rakstīt. Nevar salīdzināt, kā ir refactorēt ar testiem, un bez testiem. Tas ir tā, kā pieregulēt lidmašīnai aerodinamiku, un mēģināt lidot (produkcijā), nemaz nepamēģinot kā viņa uzvedas gaisa tunelī. Tiem, kas vēl neraksta testus - noteikti pamēģiniet. Vismaz uzsākot kādu jaunu projektu, jo no 0 vienmēr ir vieglāk + ar katru nākamo projektu, spējas noteikti uzlabosies. Vēlams izmantot kādu frameworku, piemēram, laravel, kas daudzkārtīgi atvieglo visu šo procesu. Testēšana ir ļoti overwhelming, kad paklausās, ko runā - unittesti, intergrācijas testi, end to end testing, model testing, functional testing, mocking, un vēl bonusā, viena komūna uzskata integrācijas testus par unittestiem, cita otrādāk. Nemaz nesākšu runāt par interfeisa testiem, selenium... To visu paklausoties rokas nolaižas, bez šaubām. Bet, kamēr nespersi pirmo soli, neuzrakstīsi savu pirmo, nepareizo testu, nekādu izgausmi negūsi... Tā kā novēlu - nevajag baidīties, vajag tikai pamēģināt. Oj, eseja sanāca :D