ugrás a tartalomhoz

PHP unit tesztelés

Hodicska Gergely · 2008. Jún. 12. (Cs), 23.16
Sziasztok!


Érdekelne, hogy van esetleg köztetek olyan, aki jobban belemélyedt ebbe a témába? Kíváncsi lennék, hogy itthon mennyire foglalkoznak ezzel a témával.


Üdv,
Felhő
‹ PHP E-mail gond PHP Y! pm ›
 ■
1

Fapados

janoszen · 2008. Jún. 12. (Cs), 23.18
Fapados módszer: külön entry point az alkalmazásba, amiben esetről esetre megírjuk a tesztlogikát. :) Nem túl szofisztikált, de amikor szükség van rá, akkor működik.
2

phpunit

tolmi · 2008. Jún. 13. (P), 10.48
Én phpunitot használok, bár közel sincs idő annyi tesztet írni, amennyit szeretnék. Ilyen csak a hobbikomponenseimnél nem fordul elő, ott van időm erre is :)
3

karcsú

Hodicska Gergely · 2008. Jún. 13. (P), 11.14
A visszajelzések alapján ezek szerint elég karcsú ilyen téren a PHP kultúra itthon, pedig most már elég sok jó kis eszköz van, akár maga PHPUnit plusz vannak már Continuous Integration szerverek is.

UPDATE: http://weblabor.hu/munka/21554


Üdv,
Felhő
4

Elmélkedés a magyarázatról

tolmi · 2008. Jún. 13. (P), 12.18
Ti szerencsés helyzetben vagytok, ezt azért tegyük hozzá. A legtöbb itt megforduló kollega ügyfelek projektjeinek megvalósításában vesz részt és (sajnos) igen kevés a belső projekt, mint pl az ustream.tv (AFAIK).

Az ügyfelek pedig Magyarországon ritkán hajlandók rááldozni az időt és még kevésbé hajlandóak megfizetni azt az időt, amit tisztességes CI és testing jelent. Még akkor is ha az esetek 70%-ában ez rövidebb idő alatt jelentene magasabb minőségű megoldásokat.

Természetesen meg lehet vívni velük ezt a harcot, nekünk néha sikerül is. De közel sem mondhatnám hogy pl. elégedett vagyok az ilyen jellegű infrastruktúrával nálunk és nem azért mert nem ismerjük a lehetőségeket vagy nincs rendelkezésre álló támogató technológia. Persze lehet direkt olyan ügyfeleket elvállalni, akik ebbe belemennek és meg is fizetik, de ezt is igen kevesen engedhetik meg maguknak.

A másik oldal valóban az, hogy nem ismert a dolog a fejlesztők körében, nem értik miért jó az, ha a munkájuk 60%-a sosem fog lefutni éles környezetben. A managerekről meg ne is ejtsünk szót. Nekik még nehezebb ezt eladni. Próbáld meg 10 managernek elmagyarázni, hogy miért kell a beosztottjainak az idejük 60%-t olyanra fordítani, amiért effektíve az ügyfél nem fizet. Nekik ez profitkiesés. Ez pedig keményebb dió, mint a fejlesztőkben kialakítani a kultúrát.

Végül, de nem utolsó sorban azt se felejtsük el, hogy sok olyan PHP feljesztő rohangál (sztem ez ~80%-a a mai magyar és környező országok minusz ausztria PHP fejlesztőinek), akinél ennél komolyabb kultúrális hiányosságok vannak és van még mit pótolnia ennél lényegesen fontosabb területeken is.

Márk megmondta a két fillérjét :)
5

részben talán egyetértek :)

Hodicska Gergely · 2008. Jún. 13. (P), 16.50
Ti szerencsés helyzetben vagytok, ezt azért tegyük hozzá. A legtöbb itt megforduló kollega ügyfelek projektjeinek megvalósításában vesz részt és (sajnos) igen kevés a belső projekt, mint pl az ustream.tv (AFAIK).
Ez pl. nem olyan egyértelmű. Elég nagy a tempó a startup lét plusz a konkurencia miatt is, tehát a QA szükségességét/lehetőségét nem az hozza elő, hogy simán belefér időbe plusz pénzbe, hanem egyrészt az, hogy egy idő után egyszerűen nem fér bele, hogy hibák kikerüljenek az éles rendszerbe, másrészről pedig ha jól van kitalálva ez a rendszer és jól használjuk, akkor kvázi szinte ingyen is lehet, mert a teszt kódok írására fordított idő az visszajön a debugolás során eltűnt idővel. Valamelyik slide-ban láttam 3 nagy cég felmérését unit teszteléssel kapcsolatban: a legrosszabb eset az volt, amikor 15%-kal esett vissza a temelékenység, viszont a hibák száma minden esetben drasztikusan csökkent.

Az ügyfelek pedig Magyarországon ritkán hajlandók rááldozni az időt és még kevésbé hajlandóak megfizetni azt az időt, amit tisztességes CI és testing jelent. Még akkor is ha az esetek 70%-ában ez rövidebb idő alatt jelentene magasabb minőségű megoldásokat.
Pont ezt mondod itt Te is. Szerintem vastagon benne van ebben az is, hogy nincs meg ennek a kultúrája, nem egy megszokott dolog, illetve nem is feltétlenül intuitív. Igazából én se próbáltam még unit tesztelten fejleszteni, de amikor kódot írok, akkor leginkább úgy megy, hogy apró lépésekben haladok, többnyire kipróbálok minden olyan esetet, amikor hibaágra futhat a kód, hogy lássam, hogy tényleg kezelve van (ez végülis majdnem TDD, csak paraszt verzió), és tudom, hogy mennyire utálom, amikor egy így készült alap osztályba kell mondjuk módosítani, és már nem is tudod pontosan, hogy miket kéne tesztelni, és ott a bizonytalanság. Ha lenne unit teszt, akkor lehet bátran refaktorálni.

Tehát pl. bármelyik cégenk, akinek van mondjuk egy komolyabb frameworkje, akkor megérheti, ha azt unit tesztelve tartja, mert egy abban előkerülő alattomos hiba rengeteg időt és vesződséget okozhat. Nyilván az első időszak "drágább", meg kell tanulni, ki kell tapasztalni ezt is, de szerintem megéri.

A másik oldal valóban az, hogy nem ismert a dolog a fejlesztők körében, nem értik miért jó az, ha a munkájuk 60%-a sosem fog lefutni éles környezetben. A managerekről meg ne is ejtsünk szót. Nekik még nehezebb ezt eladni. Próbáld meg 10 managernek elmagyarázni, hogy miért kell a beosztottjainak az idejük 60%-t olyanra fordítani, amiért effektíve az ügyfél nem fizet. Nekik ez profitkiesés. Ez pedig keményebb dió, mint a fejlesztőkben kialakítani a kultúrát.
Hát igen, ez valós probléma lehet, bár ez is függ a vezetőség nyitottságától is. Bár itt is lehet olyan, hogy ha pl. én nem kapok időt valamire, de biztosan tudom, hogy ez fontos, akkor adott esetben beleölök a szabadidőmből is (mert tudom, hogy hosszú távon nekem lesz jó), és ha már egy működő prototípussal állok elő, akkor már egyből jobban fog tetszeni a marketing jellegű embereknek is. Igazából nem is a unit tesztelést lehet nehéz "eladni", hanem azt az időszakot, amíg rosszul csináljuk. Gondolom a legtöbb PM kiegyezne egy profi módon működő XP csapattal. :)

Végül, de nem utolsó sorban azt se felejtsük el, hogy sok olyan PHP feljesztő rohangál (sztem ez ~80%-a a mai magyar és környező országok minusz ausztria PHP fejlesztőinek), akinél ennél komolyabb kultúrális hiányosságok vannak és van még mit pótolnia ennél lényegesen fontosabb területeken is.
Hát igen, ez így van sajnos, bár szerintem nem csak itt, mindenfele a világban lehet nagyon durva hozzászólásokat olvasni sok-sok éve PHP-ben fejelsztő emberektől.


Üdv,
Felhő
6

Re: részben talán egyetértek :)

zmb · 2008. Jún. 14. (Szo), 12.45
Hat igen, itthon az erdeklodes hianya miatt nem jellemzo a unit teszteles. Ahogy irtatok is, altalaban ezek a reakciok:
- hulyeseg
- semmi ertelme
- nincs ra ido
- az mi?

Egy biztos: unit tesztelest a projekt elejen el kell kezdeni, mert utolag mar nem lehet hozza irni. Egyreszt mennyisegi kodot kell hozza megirni, masreszt a rendszer nem feltetlen van ekkor felepitve, hogy teszteleheto legyen.
Fontos, hogy a teszt irasa legyen egszeru legyen. Ha 1 oldalban van eloallitva teszt korulmeny, akkor lehet erezni, hogy valami nem koser. A jo teszt olvasmanyos, konnyen megertheto. Tovabbi erdekes vonzata, hogy a unit tesztelt rendszerek rugalmasabbak, es kevesbe komplexek.

Javahoz irtak egy Unitils nevu eszkozt, ami az altalanos problemakat egyszerusiti le nagyban. Erdemes vegigolvasgatni a tanacsaikat, nagyon jo otletek vannak ott.
7

inkább úgy lenne az igazi

Hodicska Gergely · 2008. Jún. 14. (Szo), 14.23
Egy biztos: unit tesztelest a projekt elejen el kell kezdeni, mert utolag mar nem lehet hozza irni.
Azért lehetni lehet, csak nehezebb is, meg vlaszeg nem lesz annyira teljes. Utólag már talán nem emlékszik az ember minden apró döntésre, amit érdemes lenne tesztelni, bár elvileg a kód felülete az adott.

a rendszer nem feltetlen van ekkor felepitve, hogy teszteleheto legyen.
Igen, ez sajnos fenáll...

Fontos, hogy a teszt irasa legyen egszeru legyen. Ha 1 oldalban van eloallitva teszt korulmeny, akkor lehet erezni, hogy valami nem koser. A jo teszt olvasmanyos, konnyen megertheto. Tovabbi erdekes vonzata, hogy a unit tesztelt rendszerek rugalmasabbak, es kevesbe komplexek.
...részben ezért is szeretém elkezdeni, ez némi túlzással egy új dimenziót nyit meg a tervezést illetően. Kíváncsi vagyok ezekre a tapasztalatokra is.

Javahoz irtak egy Unitils nevu eszkozt, ami az altalanos problemakat egyszerusiti le nagyban. Erdemes vegigolvasgatni a tanacsaikat, nagyon jo otletek vannak ott.
Köszi, ezt megnézem majd.


Üdv,
Felhő
8

Ez engem is erdekelne

Protezis · 2008. Jún. 15. (V), 19.52
A topikon felbuzdulva gondoltam megnezem a PHPUnitot.

A dokumentacioban bemutatott BankAccount-os peldahoz keszitett testcase-t lehet meg boviteni, pl. szam helyett string vagy tomb atadasaval. Igy a teszt kb 2x akkora lesz, mint maga a tesztelendo osztaly. Kicsit elmelaztam ezen, es kivancsi lettem: minden metodusban ellenorzitek a parameterek tipusat, meretet stb.; vagy csak a publikus metodusokban, mondvan a privat metodusok feltetelezhetoen jo parametereket kapnak; esetleg csak a felhasznalotol erkezo adatokat ellenorzitek azokon a helyeken, ahol szukseges? Mivel azt hiszem ettol (is) fugg, mennyire "mely" teszteseteket kell gyartani. (Most az egyeb hibaktol tekintsunk el, mint pl. file I/O, adatbaziskapcsolat stb.)
9

paraméterek ellenőrzése

Hodicska Gergely · 2008. Jún. 15. (V), 20.35
A dokumentacioban bemutatott BankAccount-os peldahoz keszitett testcase-t lehet meg boviteni, pl. szam helyett string vagy tomb atadasaval. Igy a teszt kb 2x akkora lesz, mint maga a tesztelendo osztaly.
Elvileg nem kéne feltétlenül 1-1 az egyben megfeletetni az osztályokat és az őt tesztelő osztályokat. A unit tesztelés némileg továbbvitele a TDD (test driven development), ahol a teszt kód előbb készül, mint a tényleges kód, kb. a tesztelés vezérli a fejlesztést. Csak ebben az esetben nem a tesztelés a legjobb szó, mert ők úgy fogják fel a "teszt kódot", hogy az a rendszer specifikációja, tehát a specifikációt ítod meg előre (egy program formájában). majd megcsinálod a ezt megvalósító programot. Egyszer kipróbálnám, milyen lehet így dolgozni, elvileg azt mondják azok, akik már így fejlesztenek, hogy kb. max egy hónap alatt elég jól rá lehet érezni az ízére. (És vannak köztük elég komoly fejlesztők is, szóval megfontolandó a dolog.)

Kicsit elmelaztam ezen, es kivancsi lettem: minden metodusban ellenorzitek a parameterek tipusat, meretet stb.; vagy csak a publikus metodusokban, mondvan a privat metodusok feltetelezhetoen jo parametereket kapnak; esetleg csak a felhasznalotol erkezo adatokat ellenorzitek azokon a helyeken, ahol szukseges?
Szerintem ami fontos, hogy a különböző szinten lévő rétegek határain legyen ellenőrzés. Bár többnyire én azt követem nálunk, hogy mivel saját kódokról van szó, ezért ezt nem vesszük a legszigorúbban, a controller réteg feladata, hogy a bejövő változókat ellenőrizze, és megfelelően hívjon tovább a model rétegbe.


Üdv,
Felhő
10

Igaz

Protezis · 2008. Jún. 15. (V), 21.08
Elvileg nem kéne feltétlenül 1-1 az egyben megfeletetni az osztályokat és az őt tesztelő osztályokat.

Valoban nem, a unit lehet egy nagyobb entitas, pl. MVC mintat kovetve valoszinuleg sok esetben eleg a kontrollerekhez kesziteni 1-1 testcase-t. Velemenyem szerint ez attol fugg, mennyire alaposan akarunk tesztelni. Mindossze a "legrosszabb" eshetoseget neztem, amikor tenyleg minden ellenorzesre kerul.

Szerintem ami fontos, hogy a különböző szinten lévő rétegek határain legyen ellenőrzés. Bár többnyire én azt követem nálunk, hogy mivel saját kódokról van szó, ezért ezt nem vesszük a legszigorúbban, a controller réteg feladata, hogy a bejövő változókat ellenőrizze, és megfelelően hívjon tovább a model rétegbe.

Errol a PHP Doctrine jutott eszembe. Nagyon jol hasznalhato validacios lehetosegek vannak benne, ekkor viszont atharul az ellenorzes a modellre. Ezzel kapcsolatban mi a velemenyed?
11

ellenőrzés helye

Hodicska Gergely · 2008. Jún. 16. (H), 00.08
Velemenyem szerint ez attol fugg, mennyire alaposan akarunk tesztelni.
Nekem az a gondolat nagyon megtetszett, hogy a unit tesztekre ne úgy tekintsük mint tesztek, hanem mint sepcifikáció, tehát minden olyasmit kell tesztelni, amit a rendszerünk, mint funkciót, nyújt.

ekkor viszont atharul az ellenorzes a modellre. Ezzel kapcsolatban mi a velemenyed?
Jó kérdés. Magát az ellenőrzést talán jó ha a kontroller végzi, de magát a definiciót, aminek meg kell feleljen a bejövő adat, azt valahol a modelnek kell tartalmaznia, hisz ő tudja, hogy mire is van szüksége. Adott esetben el tudom képzelni, hogy az ellenőrzés az a modellben lévő metaadatok (docblock komment + annotation) alapján automatikusan történik.


Üdv,
Felhő
13

Domain model

tolmi · 2008. Jún. 17. (K), 11.41
...ekkor viszont atharul az ellenorzes a modellre.

Tulajdonképpen a kollega feltette az egyik legvitatottabb kérdést a szakmában. Ti. hol kell a domain model-t megvalósítani. Most már azért kezd körvonalazódni egy válasz, amelyben a frakciók úgy-ahogy megegyezni látszanak szerintem. Ez pedig a hibrid megoldás, azaz maga a modelldefiníció az a Model rétegbe kell tartozzon, de a domain tulajdonságokat a controllerben kell érvényesíteni. Tehát a validáció az controller szerep kellene legyen és nem modell szerep.

Ez, ha belegondoltok, így helyes, hiszen ha a modellben lenne a domain tulajdonság (pl. validáció és konzisztenciaellenőrzés), akkor felesleges köröket futnánk a view-től a modellig a controllereken át, valamint az automatikus view ellenőrzések (pl. JS-ben megvalósítva) így közvetlen a modellt kell hívják, amit ugye szeretnénk elkerülni, hiszen nem véletlen döngetjük a mellünket az MVC-vel, ugye? :)

A másik kellemetlen dolog ami felmerülhet, az a portolhatósági és szakaszhatárok menti függetlenség. Ha a modell rétegben van domain tulajdonság, akkor bizony magának a modell absztrakciót biztosító eszköznek (pl. Doctrine) kell implementálnia ezt a viselkedést minden támogatott perzisztencia-eszközhöz. Ez pedig gyakran azt jelenti, hogy hatalmasra duzzadnak ezek a könyvtárak, ami nekünk felhasználóknak nem jó (lásd Doctrine, mint ékes példa a nagy kódbázisból eredő bugokra és azok élettartamára).

Szóval megfontolandó hogy akar-e a tervező úr/hölgy domain logikát szőni a modellbe, ahelyett hogy a modell-t "butának" kezelné és csak minimális absztrakciót vár el tőle.
14

Viszont...

hector · 2008. Jún. 17. (K), 13.55
Viszont ha a modellben van az ellenőrzés, akkor elég egy helyen megvalósítani, egyébként meg kontrollerenként külön-külön.

Nálam ez így megy:

try
{
    $user = new User();
    $user->fromArray($_POST);
    $user->id = null;
    $user->save();
    $this->goto('list');
}
catch (Doctrine_Validator_Exception $e)
{
    $this->view->record = $user;
    $this->view->errors = $user->getErrorStack();
    $this->display('new');
}
Nincs külön validálás, a modell ellenőrzi az adatokat (végeredményben az adatbázis maga is végez ellenőrzést, szóval miért ne?).

(bocs, hogy belekotyogok, csak érdekel a téma :))
15

Örömmel veszem, ha valakit érdekel!

tolmi · 2008. Jún. 17. (K), 15.51
No, elolvastam néhány whitepaper-t az MVC-ről és neked van igazad. Az MVC és ráadásul az MVP is azt a megközelítést követi hogy a model-be teszi az információt manipuláló kódot azaz a domain model-t is oda kell tenni. A domain logic-ból vagy business logic-ból pedig csak az kerül a controllerbe, ami az állapotváltozás magas szintű lekezeléséhez kell. Úgyhogy papírforma szerint te csinálod jól.

Mi ennek a mambo-jambo-nak a lényege? Praktikusan semmi. Itt csak elvekről van szó. Így felvilágosodva viszont azt kell mondanom hogy nem értek egyet az MVC-vel a következők miatt:
Nem vagyok hajlandó elfogadni azt, hogy az információval/adattal kapcsolatos állapotok és viselkedések a Model réteg sajátosságai. Ennek praktikusan a controller rétegben lenne a helye.
16

Megoldhato

Protezis · 2008. Jún. 17. (K), 16.08
Technologiailag megoldhato, hogy a validacios fuggveny(eke)t a controllerben irod meg, es a modellbol automatikusan hivod az(oka)t.

Egyebkent nem tul trivialis lekezelni egy sima felhasznalo regisztraciot sem. Tegyuk fel, hogy van egy captcha, valamint ketszer kell begepelni a jelszot. Ezeket a controllerben ellenorizzuk, a model meg se kapja ezeket az adatokat. Ezert pl. hibas captcha eseten meg se probaljuk elmenteni a modelt, a muvelet ugyanis sikerulne. Ellenben mi tortenik, ha a hibas captcha mellett olyan felhasznalonevet adott meg a user, ami mar letezik? Ezt a model ellenorizne, de mivel el se jut a muvelet a modellig, eleg bonyolult elerni azt, hogy mindket hibarol tudomast szerezzunk, illetve azokrol ertesitsuk a usert. Bar az is lehet, hogy erre van valami megoldas a Doctrine-ban, tulsagosan nem melyedtem meg el benne.

Egy picit eltertunk a tematol, ugyhogy ha gondoljatok folytassuk mashol :)
17

explicit validálás

hector · 2008. Jún. 17. (K), 16.23
A Doctrine_Record-nak van egy isValid() metódusa, azzal bármikor ellenőrizhetők a modell paraméterei. Az általam mutatott példában a save() metódus előbb ezt hívja meg, majd az eredménytől függően lefuttatja az adott SQL query-t, vagy dob egy exception-t.

Én egyébként azért vagyok modell párti ebben a dologban, mert mint fentebb említettem, végeredményben maga az adatbázis is elvégez egy ellenőrzést az adatokon (típus, constraint-ek, etc.), mielőtt elmentené a rekordot. Így nekem kézenfekvőnek tűnt, hogy akkor ez a feladat magasabb szinten is maradjon a modellnél.

szerk.: folytathatjuk máshol is, ha nem értünk egyet :)
18

OK

Protezis · 2008. Jún. 17. (K), 16.43
A Doctrine_Record-nak van egy isValid() metódusa, azzal bármikor ellenőrizhetők a modell paraméterei. Az általam mutatott példában a save() metódus előbb ezt hívja meg, majd az eredménytől függően lefuttatja az adott SQL query-t, vagy dob egy exception-t

Ezzel teljesen tisztaban vagyok. Epp azt irtam, hogy mi van, ha nem a model elemeivel van a gond, illetve ha nem csak azokkal. Vagy az isValid()-nak adod at a masodik jelszot es a beirt captcha stringet?
19

Ja, így már értem

hector · 2008. Jún. 17. (K), 18.27
Jó kérdés. Ebben az esetben azt csinálnám, hogy a captcha és a jelszó validálását a kontrollerre bíznám, a többi maradna a modellnek. Hogy miért? Elsőre csúnyának tűnhet, hogy két külön rétegre bíztuk az ellenőrzést, de ha belegondolsz, az általad említettek egyike sem a modellt védi: a captcha a szkripteket tartja távol, a jelszó megerősítése pedig a felhasználót segíti abban az esetben, ha elgépelte a jelszavát. Így nézve szerintem teljesen elfogadható a kettéválasztás.
20

Vagyis?

Protezis · 2008. Jún. 17. (K), 18.53
Nekem masodjara se tetszik, habar igy csinaltam. Es ekkor jon elo az a problema, amit a #16-ban irtam. Hibas captcha + letezo felhasznalo nev. Utobbi csak akkor derul ki, ha nyomsz egy save()-t, amit nem tehetsz, mert hibas a captcha, es ott meg nem tudod, jo lesz -e a felhasznalo nev vagy sem. Igy csak az derul ki, hogy hibas a captcha, az nem, hogy a felhasznalo nev se lesz jo. Igy plusz 1 kort fog futni a user ( arrol ne is beszeljunk, hogy a felhasznalo nev modositasakor esetleg elfelejti atirni a modosult captchat ).
Persze megnezheted a controllerben, hogy letezik -e a felhasznalonev, de miert tenned, ha az a model feladata? Ezt hogy lehetne szepen megoldani?
21

Ehhez mit szólsz?

hector · 2008. Jún. 17. (K), 19.36
Csak egy gyorsan összedobott skicc (Zend Framework használatával):

$user = new User();
$user->fromArray($_POST);
$user->id = null;

// Zend szűrő és validátor létrehozása a jelszó
// megerősítéséhez és a captcha-hoz
...
$input = new Zend_Filter_Input($filters, $validators, $_POST);

// ha minden oké
if ($user->isValid() && $input->isValid())
{
    $user->save();
    ...
}

// ha valamelyik validátor elbukik
$this->view->errors = array('model' => $user->getErrorStack(),
                            'other' => $input->getInvalid());
szerk.: kicsit szétesett a kód az oldalszélesség miatt, bocsesz
23

Hm...

Protezis · 2008. Jún. 17. (K), 22.02
Ha a nev egyedinek van definialva az adatbazisban, akkor a Doctrine az isValid() hivasakor ellenorzi, hogy az adott model sikeresen mentheto lenne -e a tablaba? (Ki is probalhatnam, de inkabb holnap vizsga utan :) )
24

Yepp

hector · 2008. Jún. 17. (K), 22.39
Igen, lecsekkolja a unique constraint-et is. Sőt, amivel egyszer jól megszivatott, hogy ha email címként definiálsz egy mezőt, akkor leellenőrzi a dns mx rekordot. Offline fejlesztésnél eltartott egy darabig, míg rájöttem, hogy miért hasal el mindig az email validálás.
25

Koszonom

Protezis · 2008. Jún. 17. (K), 22.53
Megint okosabb lettem :)
Az e-mail ellenorzesrol tudtam. Szerintem jo igy, regularis kifejezessel barmikor helyettesitheto, ha nincs szukseg az ellenorzesre.
22

nem ugyanaz a kettő

Hodicska Gergely · 2008. Jún. 17. (K), 21.25
A captcha az szerintem egyértelműen nem gond jelen kérdéskörben. Az szerintem egyértelműen kontroller réteg, hisz csak az a cél, hogy biztosítsa, hogy ember használja a programot. Nézd mondjuk olyan szempontból, hogy ha mondjuk parancs sorból szeretnél regisztrálni, akkor ott ez szóba se jönne. Ha a captcha nem jó, akkor a modell réteg meg sem "szólítódik".

A két jelszó kérdése meg szerintem szintén ugyanez az eset, bár talán nem annyira egyértelmű. De itt is valahol egy a modelltől igazából független, emberi tényező miatt szükséges valamiről van szó. Itt is igaz lenne, ha pl. van egy fájlod, ami tartalmazza az új usereket, és mondjuk ez lenne a kontroller inputja, akkor eszedbe sem jutan a modellben ilyesmit csinálni.

És pont az ilyesmik miatt is tetszik nekem egy olyan megközelítés, hogy a kontroller el tudja kérni a modelltől a számára szükséges validátorokat, ezt ki tudja egészíteni a sajátjaival, és ez alapján történik meg a kérés validálása.


Üdv,
Felhő
26

Hupperesen

tolmi · 2008. Jún. 18. (Sze), 13.18
+1 (csak így hupperesen ;))
12

ugyanez nálam

hector · 2008. Jún. 16. (H), 00.35
Érdekes, ugyanezen filóztam pár hónapja az egyik munkám során. Nem tudtam dönteni a Zend_Validator, és a Doctrine validátora között. Végül a Doctrine-re bíztam a dolgot, mivel az ellenőrzést automatikusan elvégzi az adatbázis mezők definíciója alapján (amit ugye így is, úgy is meg kell csinálni). Bár volt egy másik eset, ahol viszont kifejezetten zavaró volt ez a megoldás (valami probléma volt a Doctrine blob értelmezésével), ott kénytelen voltam kikapcsolni a modell saját ellenőrzését, és átadni a munkát a Zendnek. Egyszóval szerintem esete válogatja.
27

kötelező :)

virág · 2008. Jún. 18. (Sze), 15.50
szia, nálunk kötelező, (Symfonyt használunk) minden fejlesztőcsapatnak kötelező teszteseteket írni, majd abból teszteket csinálni, van rá külön ember aki felelős a tesztekért, és a kollégák ezirányú tudásáért, ha új ember jön akkor kiokosítja stb., vannak belső agytágító doksik, megbeszélések erről (is).
28

Ez hol, melyik?

Adam · 2008. Jún. 21. (Szo), 13.27
Ha nem túl indiszkrét, ez melyik cég? Nem sok van Magyarországon szerintem, ahol ilyet megkövetelnek, és felcsigáztál :) Esetleg nincsenek publikussá tehető doksitok?

UPDATE: esetleg nincs mostanában ott valami lehetőség?