Izrada github Tests foldera - pomoć

Molio bih gurue za pomoć s githubom.
Kako napraviti Tests folder (automatizam ili kako to ide?) i šta u njemu mora biti?
Ajmo reć da imam file
Hello.php i u njemu (ovo lupam na pamet):

 Class HelloWorld { 
     public function sayHello ($name)
         { 
              echo "Hello ".$name;
              return true;
         }
 }

I dignem na github.
I sad trebam taj tests folder. Kako ga ispravno napraviti i šta u njega staviti (da se testira ova gore klasa?).
Napominjem - da bude po “pravilima službe”. :slight_smile:

Pokušavao sam nać nekakvo objašnjenje/tutorijal na tu temu ali nisam našao (ili sam pogrešno tražio?).

Hvala na pomoći!

Nisam bas najbolje razumio pitanje.

Da bi testirao nesto, prije svega ti treba neki Testing framework, koliko znam za PHP je PHPUnit popularan.

Po default-u, framework bi trebao naci sve fajlove koji zavrsavaju na Test.php i ukljuciti ih.U tvom slucaju file bi se trebao zvati HelloWorldTest.php.

https://phpunit.de/manual/6.5/en/organizing-tests.html

Ne, ne unit testing :slight_smile:
Kad odeš na github i tamo pogledaš neki code, vidjet ćeš da ima source code (obično u src folderu) i Tests folder gdje se nalaze “test case”-ovi tog code-a. To ne zanima, kako se to postavlja, ide li to automatizmom ili kako već.

Pa kreiras lokano folder i unutra stavis sve sto treba biti , commit , push , merge u master itd.:grin:

Ali kaj da stavim u taj “Tests”? Proizvoljno kaj mislim da treba ili postoji neko pravilo?

Zasto bi imao Tests folder ? Samo zato jer i drugi imaju.

Boli te djon za druge.

1 Like

Ak ne moram onda ok. Mislio sam da to tak mora :slight_smile:

Neki rade testove, neki ne.
Osobno za hobi projekte ne bi radio testove.

Nije zbog hobija, već principa rada (učim). Ak me razumiješ kaj hoću reć :slight_smile:

Prateći PSR-4 file name i class name trebaju biti isti.

The terminating class name corresponds to a file name ending in .php . The file name MUST match the case of the terminating class name.

File name HelloWorld.php, class name

<?php

class HelloWorld
{
}

Isto je i sa test klasama. Ime fajla i ime klase trebaju biti isti (vjerujem da se izbjegava dodatna komplikacija od podešavanja kao u slučaju kad nisu).
U composer.json se u dev sekciju ubaci namespacing i source na sličan način k’o što se postavlja za originalni kod.

Evo kako struktura izgleda kod Slim framework-a

1 Like

Vrlo vjerovatno da mora, ako firma u kojoj radis ima praksu testiranja koda :smiley: Mada u tom momentu ti ne bi trebao brinuti o strukturi, jer ce sve biti unaprijed definirano - tvoje je samo da testiras svoj kod.

Ako firma nema praksu testiranja, onda ces vjerovatno cuti frazu kako su testovi gubljenje vremena i nista od spomenutog ti nece trebati (bar ne u toj firmi) :slight_smile:

Da i ne.
Tu ima vise problema, problem je taj sto rijetko koja firma ima sw arhitekta i u rijetko kojoj se pise dokumentacija za developere.

I onda iz ovog proizlazi da su testovi potrebni.
Ako je prije razvoja sve dobro razradjeno i dokumentirano, tvrdim da ce biti manje bugova, nego kad se radi iz tiketa + testovi.

Kad imas dokumentaciju za developera, radis testiranje u test okruzenju.

Zato postoje tri okruzenja: dev, test i produkcija.

Znam, pisao sam na telefonu i čisto primjera radi (ok, moja greška, trebao sam se i tada držati psr) :slight_smile:

I to je jasno - jer držiš se PSR-4 u svakom slučajum bez obzira o čemu se radilo.

Pitanje je postoji li neko pravilo sa tim Tests folderom i što u njemu zapravo treba biti testirano u tvojem kodu, ili je to proizvoljno i ti sam odlučuješ na koji način ćeš testirati. Odnosno, da li je taj “Tests” folder baš za testiranje (poput PHPUnit code-a) ili je to više kao “example” kako koristiti svoj code?

Jao kad se sjetim lika, bilo je to prije 20 godina, došao studirati ovdje i volio računare. Pravio virus, još u aktualnom DOS-u pa je radio promjene u command.com datoteci. I svaki test je završavao ponovnom instalacijom Windows 95 i analizom što je virus uradio a što ne, kako da ovo kako da ono… Uporan i nadasve jako zanimljiv lik.

Napomena: sve je radio na svom PC , jedinom kojeg je imao. U to vrijeme se nije moglo imati 2 ili više PC doma. Jedan MMX I glavni si u selu . Norton Comander bio kao danas Visual Studio 2018 ili što već . Sjetim se , pa upao u temu . Samo nastavite.

2 Likeova

Nego: da malo uđem u temu.

Sada mene zanima, što točno dobijete jednim test folderom? Zar se kod ne može testirati dok se radi na njemu “live preview” ono kao u nekom Win programskom alatu.? Pitam jer, kako neki test folder može simulirati stvarno okruženje u kojem će se web aplikacija izvoditi? Šta bude u test folderu, a da nemate u strukturi foldera u kojoj zapravo programirate?

Ne govorimo o istom test folderu :slight_smile:
Evo primjer (isčupao sam ga bezveze):

Ima dva foldera: src i test
Taj folder “test” je predmet mojeg topica i o njemu nastojim saznati “šta i kako” (kao što sam gore pitao).

Ovo o čemu ti zboriš je “unit testing”, a zašto se koristi najbolje je objašnjenje ovdje (ujedno i sa primjerom, ali samo objašnjenje zbog čega koristiti unit testing je savršeno jasno):

Osobno nisam do sada radio sa unit testingom, ali to sad nije niti bit :slight_smile:
Muči me github i taj test folder i šta u njega postaviti, osnosno postoji li pravilo što u njemu mora biti ili je to proizvoljno i demonstracija rada tvog code-a…

@dmitrecic
Pogledaj kako to rade najveći (ipak su oni prvaci u organizaciji koda), da ne linkujem sad:
Google PHP API ili Facebook graph SDK
mada je Slim tu sa njima po izgledu tests direktorijuma.
Vidi strukturu tests-a i šta je postavljeno u phpunit.xml.dist fajl.
Uporedi ih pa ćeš vidjeti šta i kako. Ima i do proizvoljnosti ali ovi pomenuti recimo koriste tests plural za directory name i bootstrap.php fajl u nomenklaturi za inicijalizaciju.

1 Like

Dakle to je to. Unutra idu unit tests. Nije mi bilo jasno šta ide u taj folder jer sam kod nekih primjetio (poput ove koju sam stavio za primjer na github-u) da su unutra zapravo “example” codovi kako koristiti klasu, a ne unit testovi.
E sada je jasnije - tu (tests folder) bi trebali biti unit testovi klase.

Ne moraju nuzno ici unit testovi, i ne mora se nuzno zvati dir “test” ni “tests”. Moze se zvati i “foobar” ako zelis i mozes ih organizirati kako god ti hoces.

Zapravo zasto bi uopce pisao testove? Cilj je da kad pokrenes testove dobijes informaciju ako si nesto strgao, ilitiga da sve radi kako treba raditi ukoliko svi testovi prodju.

Stoga pisemo testove jer ih racunalo moze jako brzo izvesti automatski u par sekundi/minuta za ono sto bi tebi trebalo rucno puno duze vremena (+ otvaranje browsera ili komandne linije, sto je sporo i nepotrebno).
Plus preciznije je, racunalo nece zaboraviti nesto testirati kao sto bi human mogao zaboraviti.

Vrijedi napomenuti da osim unit testova postoji jos tipova testova poput integracijskih, funkcionalnih, acceptance, end-to-end, smoke testova itd… Zargon oko testiranja je cesto konfuzan i opcenito cijela zajednica se jos ne moze dogovoriti oko nekih konvencija i naminga, tako da te to ne zbunjuje.

Prema tome pises testove na onaj nacin i za sve ono sto tebi kao developeru govori da, ukoliko su mi svi testovi prosli, aplikacija ili library zaista rade. Ne pises testove samo zato jer ih i svi ostali pisu, niti ih pises u istom stilu kako svi ostali pisu, sve zavisi od same aplikacije s kojom radis i tvojim potrebama.

S obzirom da se bavis PHP-om, preporucam da pogledas neki od popularnih PHP repozitorija na Githubu kako testiraju kod, poput Laravela.

Usput: repozitorij koji si linkao u jednom od prethodnih postova ne trebas gledati kao ogledni primjer kako se kod pise ili testira, jer su i kod i testovi jako losi.

1 Like

Hvala! Eto to sam htio znati. :slight_smile: