ugrás a tartalomhoz

Accessing private PHP class members without reflection

Gixx · 2015. Júl. 7. (K), 15.26
Privát tulajdonságokhoz való hozzáférés ReflectionClass nélkül, akár referenciával is
 ■
1

Deeee..

vbence · 2015. Júl. 8. (Sze), 10.04
Ez nem az amit NEM SZABAD csinálni?
2

Normál esetben nem

Gixx · 2015. Júl. 8. (Sze), 11.14
..., de UnitTesteknél jól jöhet.
3

Ott sem szabadna elerni

blacksonic · 2015. Júl. 9. (Cs), 11.06
Ott sem szabadna elerni
4

Ezt sokan mondják, miközben

Joó Ádám · 2015. Júl. 9. (Cs), 15.38
Ezt sokan mondják, miközben az egységtesztelés szinte mindenhol fehérdobozos tesztelés – szóval miért is ne?
5

A teszttel nem a belso

blacksonic · 2015. Júl. 9. (Cs), 16.53
A teszttel nem a belso mukodest kell tesztelni, ha elindulsz a privat dolgok tesztelesenek az utjan es refaktoralni akarsz...mert hat a privatot miert ne irhatnam at csak azaz osztaly hasznalja...you gonna have a bad time. Meg alapvetoen semmibe veszi az egysegbezarast.
Ha nagyon kellene valami privatot tesztelni, ott lehet egy masik osztaly stb bujik meg es jobb kiemelni es kulon tesztelni.
6

Ezt sokat hallani. Ehhez

Joó Ádám · 2015. Júl. 9. (Cs), 17.59
Ezt sokat hallani. Ehhez képest mindenki, akit eddig láttam az implementációt figyelembe véve írja a teszteket, elágazások, ciklusok és kivétel-blokkok mentén, és általában ezt lefedettségi metrikákkal ellenőrzi is.

Ha valóban csak a felületet tesztelnéd, akkor a függvényed teljes értelmezési tartományát bejárnád, az összes paramétered összes kombinációját végigpróbálva. Gyanítom, hogy te sem így csinálod.
7

akit eddig láttam az

BlaZe · 2015. Júl. 9. (Cs), 22.01
akit eddig láttam az implementációt figyelembe véve írja a teszteket, elágazások, ciklusok és kivétel-blokkok mentén
De hát akkor még meg sincs a kód, amikor a tesztet írod ;)

A viccet félretéve azt tudod, hogy az adott implementáció milyen inputra milyen outputot kell adjon. Ehhez semmit nem kell tudni a belső működéséről. És butaság is a tesztet bármilyen belső működéshez, változóhoz stb kötni. Csak a refaktor költségét növelik, és ha a teszt nem tudja ezt nélkülözni, akkor az inkább valami tervezési hibára utal.

Én egyetértek vbencével és blacksonic-kal. Soha nem csináltam ilyet és nem is szeretnék.
8

Tehát hogyha például a

Joó Ádám · 2015. Júl. 9. (Cs), 22.39
Tehát hogyha például a paraméterek bizonyos tartományára optimalizálsz, akkor azt az ágát nem fogod tesztelni a kódodnak?
9

De, de miért kéne ehhez

BlaZe · 2015. Júl. 9. (Cs), 23.16
De, de miért kéne ehhez private változót elérnem a tesztből? Annak semmi köze a branch coverage-hez (ha erre akarsz kilyukadni).

Nyilván ahhoz, hogy letesztelj valamit, ismerned kell az elvárt funkcionalitást. De senki nem ezt vonta kétségbe, hanem azt, hogy ehhez belső változókat kell elérni. Amikor manuálisan tesztelsz egy rendszert, akkor sem debuggerrel nézed, hogy mik a különböző változók értékei. Az eredményre vagy kíváncsi, amit a végén kiköp pl egy clickre.
10

Pusztán logikailag

zzrek · 2015. Júl. 9. (Cs), 23.31
Pusztán logikailag: nem fordulhat elő olyan eset, amiben a funkcionalitás, az eredmény minden esetben egy belső változótól függ, amelynek a tesztelése sokat segíthet a hibafelderítésben?
11

A debugolást, meg a

BlaZe · 2015. Júl. 10. (P), 00.09
A debugolást, meg a tesztelést ne mossuk össze. Akkor se, ha tesztekkel lehet jól debugolni. Arról beszéltünk, hogy jó-e az ha tesztek belső változón függnek. Nem arról, hogy lehet-e indokolt belső változót elérni.
12

De, de miért kéne ehhez

Joó Ádám · 2015. Júl. 10. (P), 00.54
De, de miért kéne ehhez private változót elérnem a tesztből? Annak semmi köze a branch coverage-hez (ha erre akarsz kilyukadni).


Arra akarok kilyukadni, hogy a tesztjeid írásakor az implementáció ismeretére támaszkodsz, mert a tesztjeid lényege, hogy megerősítsd magad abban a hitedben, hogy amit leírtál, az úgy működik, ahogy gondolod (ezért fogsz néhány tudatosan kiválasztott paraméterkombinációt kipróbálni, amivel minden vezérlési utat bejársz), nem pedig az, hogy a specifikáció ismeretében validáld az implementációt (ebben az esetben minden paraméterkombinációt ki kellene próbálj).

Ha ebben megállapodtunk, akkor innentől hibás érv a privát változók vizsgálata ellen, hogy az implementációs részlet, mert az optimalizálás is az, és egy refaktorálás esetén ugyanúgy kell mindkét esetben a kód után igazítani a tesztet (csak míg ha felszámolsz egy változót, akkor el fog törni a teszt, addig ha mondjuk nagyobb tartományra kezdesz cache-elni, a tesztjeid szép csendben nem fogják lefedni azt az ágat).
13

Annyit kell tudnod a belso

blacksonic · 2015. Júl. 10. (P), 09.31
Annyit kell tudnod a belso implementaciorol hogy azok a reszek amik kulso eroforrasokhoz nyulnak pl adatbazis, halozat milyen az interfeszuk, hogyan tudod oket mockolni.
Tobbi esetben szerintem nem kell tudnod belso mukodesrol.
20

function f(i) {

Joó Ádám · 2015. Júl. 10. (P), 17.01
function f(i) {
    precomputed = {
        // ...
    }
    
    if (i < 256) {
        return precomputed[i];
    } else {
        // expensive calculations
    }
}
Így érthető?
21

De ez tipikusan dependency

BlaZe · 2015. Júl. 10. (P), 17.50
De ez tipikusan dependency (config, valamilyen storage, másik class stb) és injecteljük, nem?
24

Attól függ, hogy az éles

Joó Ádám · 2015. Júl. 10. (P), 18.05
Attól függ, hogy az éles kódomban akarom-e cserélni. Ha nem, akkor csak a tesztelhetőség kedvéért nem fogom kiemelni.

Ez a baj ezzel a megközelítésével a unit tesztelésnek. Gondolj bele, mi is történik itt: csak azért, hogy elmondhassam, hogy én nem foglalkozom az implementációval – mert akkor a refaktoráláskor követnem kell a tesztjeimmel – az implementáció egy részét a kiemeléssel a specifikáció részévé teszem – és innentől egy refaktoráláskor még több munkám lesz a tesztek hozzáigazításával. Nyerni nem nyertem semmit, viszont ennyivel is komplexebbé tettem az interfészem.

Véleményem szerint a tesztelésnek, hibakeresésnek nem volna szabad befolyással lennie az architektúrára. Azt nem mondom, hogy az elérhető eszközök ezt minden esetben lehetővé teszik ma, de a mostani megközelítés mellett nincs is különösebb nyomás az ilyen irányú innováción.
14

Tegyük fel

Gixx · 2015. Júl. 10. (P), 10.25
Tegyük fel, hogy használok egy akármilyen keretrendszert, amiben csinálok egy akármilyen egyedi dolgot (model, controller, action akármi). Csakhogy az akármilyen keretrendszer használ egy tonna private/protected változót, amihez nem ad gettet/setter funkciókat (amiket ugye lehetne mockolni) csak szimplán írja/olvassa azt a bizonyos `$this->_screwPsr2` tulajdonságot, amit sok esetben nem közvetlenül te szabályzol, hanem configok, initek, preDispatchek, helperek hadán keresztülverekedve a rendszer egy teljesen másik részén valahol egy olyan környezeti változó által lett befolyásolva, ami CLI-ben nem létezik, vagy más az értéke.

Én elég gyakran belefutok ilyenbe. Nem én döntöm el, milyen keretrendszert használunk, így az a lehetőség, hogymást használok kilőve. Sőt, jelenleg egy ismert keretrendszerre épülő licenszelt e-commerce szörnyetegbe kell új dolgokat fejleszteni. Vagyis se a keretrendszert, se a szörnyeteget nem módosíthatjuk, csak a saját kiterjesztéseinket babrálhatjuk.

Vagyis én a munkám során kétlehetőség közül választhatok:

1. szétbarmolom a keretrendszert és a szörnyeteget mindenféle öröklésekkel és kiterjesztésekkel, bevezetve egy sor fölösleges getter/setter funkciót (magyarán elérhetővé téve a rejtett tulajdonságokat), hogy egyszerű legyen tesztet írni.

2. a fenti módszerrel simán felülvágom azt a nyamvadt változót, hogy a funkcióm tesztelésére tudjak fókuszálni anélkül, hogy a komplett rendszert be kellene izzítani hozzá.

Bár szinte bizonyos, hogy most sokan nyomtak egy facepalmot, és elkönyveltek Zs-kategóriás web-kontárnak, de én akkor is a 2. megoldást választom.
15

Miért nem hagyod ott a céget?

Hidvégi Gábor · 2015. Júl. 10. (P), 12.10
Miért nem hagyod ott a céget? Ebből a helyzetből csak rosszul jöhetsz ki, hisz állandóan kompromisszumokat kell kötnöd a hibás választásuk miatt.
16

Dehogy hagyom itt

Gixx · 2015. Júl. 10. (P), 14.53
Miért hagynám itt?? Jó a hely, jó a munka, jók a kollégák, jó a fizu is. Nincs semmi bajom a hellyel vagy a munkával. Az hogy a RocketInternet által promótált kóddal kell dolgozni az egy dolog. Ez van. Még mindig jobb, mintha Drupal lenne, hahaha :D

De ha ezt csak azért mondtad, mert esetleg szerinted csak az a jó munkahely, ahol a fejlesztés a legüberkúlabb trendekhez igazodik, hogy habosra verhesse a brét, hogy milyen istenkirályos megmondóemberes piacvezetős... És emiatt nem nyúl a privát dolgokhoz, mert hogy azt nem szabad? Az ilyen hozzáállás annyira piti már...

Itt errefelé ez a rákot se érdekli. Az ilyesmi nem mércéje a minőségnek. Ha jó, hasznos és működik, akkor nem vetjük el azért, mert valami divatos hiszti miatt boszorkányságnak lett kikiáltva.

És nekem személyszerint nagyon tetszik a fenti megoldás, itt elfogadják az ilyet, nem démonizálnak bele nem létező problémákat.
17

Te fogalmaztál így:jelenleg

Hidvégi Gábor · 2015. Júl. 10. (P), 15.03
Te fogalmaztál így:
jelenleg egy ismert keretrendszerre épülő licenszelt e-commerce szörnyetegbe kell új dolgokat fejleszteni
Előtte felsoroltad, milyen problémák vannak a teszteléssel. Ha ezek ellenére elégedett vagy, el ne menj onnan!

szerinted csak az a jó munkahely, ahol a fejlesztés a legüberkúlabb trendekhez igazodik
Távol áll tőlem bármit is azért használni, mert trendi.
19

Nem probléma

Gixx · 2015. Júl. 10. (P), 15.58
Bocsánat, hogy félreérthetően fogalmaztam (megint).

Nem minden feltétlenül rossz, ami szörnyeteg. Szörnyeteg, mert néhol túlbonyolított azért, hogy általánosan megfeleljen a legtöbb e-commerce követelménynek. Sok esetben nekünk nem kell belőle minden, nem a mi cégünkre lett kihegyezve. Szörnyeteg, mert PHP 5.1-re íródott, így akadnak néha javítani való dolgok. Szörnyeteg, mert sok helyen nincs dokumentáció. Szörnyeteg, mert csúnyán bele kell mock-olni a unit tesztek során. De ettől még tökéletesen jó arra a célra, amire a cégünk használja.

Olyan, mint egy 1971 Dodge Charger. Nem új, nem kicsi, nem optimalizált, de ha fel kell tépni az aszfaltot, arra tökéletesen alkalmas :D

És örülök, hogy nem a trendiség hajt, ezért is indult a mondat feltételes móddal :P
18

Azért az elhangzott érvelések

bamegakapa · 2015. Júl. 10. (P), 15.34
Azért az elhangzott érvelések nekem logikusnak hangzottak, nem divatos hisztinek, de mindenkinek lelke rajta.
22

Nekem azért a fenti

Joó Ádám · 2015. Júl. 10. (P), 17.52
Nekem azért a fenti beszélgetés alapján úgy tűnik, hogy márpedig vannak itt le nem tisztázott alapelvek, és egy készen kapott elmélet áll szemben a valódi gyakorlattal. Persze lehet, hogy én látom rosszul.
23

Már sok ilyen vitát láttam,

Hidvégi Gábor · 2015. Júl. 10. (P), 17.55
Már sok ilyen vitát láttam, nem hiszem, hogy dűlőre lehet a témában jutni.
25

Mindkét oldalnak vannak jó

bamegakapa · 2015. Júl. 10. (P), 23.00
Mindkét oldalnak vannak jó érvei, tehát nem a bré veréséről van szó, én csak ezt mondom.