Newsgroup: it.comp.www.php
Titolo: testare valore visualizzato da una funzione

function abc() {
     return 'ciao';
}
 
assert(abc() == 'ciao');
 
 
Tutto ok, ma se la funzione fosse stata cosï¿œ:
 
function abc() {
     echo 'ciao';
}
 
come si fa a testare un valore non restituito, ma visualizzato direttamente?

 direttamente?
 
Intanto non dovresti avere funzioni che stampano, ma solo che ritornano 
valori, ma per i casi particolari (template engine, per esempio) puoi 
usare ob:
 
ob_start();
abc();
assert(ob_get_clean(), 'ciao');
 
Bye.


si, però funzioni che stampano ce ne sono:
 
var_dump(...);
print_r(...);
exit(...);
 

 exit(...);
 
Sì, ci mancherebbe altro.
Ma perché dovresti usarle in una funzione o, peggio, in una classe?
 
Se devi stampare qualcosa a schermo devi essere un template engine (o 
pochi altri casi specifici).
 
Se devi uscire con un errore, lancia un'eccezione.
 
Se devi fare un dump, fallo su file (o, meglio, su uno stream).
 
In tutti gli altri casi, una funzione deve tornare un risultato con 
return o modificare lo stato dell'oggetto in cui si trova, ma non scrivere 
a schermo.
 
Bye.

 pochi altri casi specifici).
 
O, meglio ancora, nemmeno loro. Implementa semplicemente un __toString(), 
poi sarà l'utente a decidere quando usare "echo $template" nel suo main 
frontcontroller o quello che è.
 
Bye.


 
un esempio di dumping su stream? (se non chiedo troppo)
 


 
Ah forse php://stdout, giusto?


class TemplateEngine {
     function __toString(){
         return 'Hello!!!';
     }
}
 
$template = new TemplateEngine('Hello');
echo $template;
 
 
Così?

come si fa a testare un valore non restituito, ma visualizzato direttamente?
 
In tanti modi, nessuno efficiente.
 
Suggerimento: NON visualizzare mai nulla nelle funzioni :-)
 
function assert_output($output, $callback) {
	ob_start();
	$ret = $callback();
	$out = ob_get_contents();
	ob_end_clean();
	assert(preg_match($output, $out));
	// Magari ulteriori asserzioni su $ret, sai mai.
}
 
Leonardo
 
-- 
 
Questi non hanno speranza di morte; e la lor cieca vita e' tanto bassa,
Che 'nvidiosi son d'ogne altra sorte. Fama di loro il mondo esser non lassa;
Misericordia e Giustizia li sdegna; non ragioniam di lor, ma guarda e passa.

 }
 
Come già accennato nell'altro postm dai un occhiata qui [ metodo debug() ]
http://symfony.com/legacy/doc/jobeet/1_4/it/09?orm=Doctrine
 
 
Quindi i geni che hanno scritto Doctrine non sono poi così geni :-P
 


http://symfony.com/legacy/doc/jobeet/1_4/it/09?orm=Doctrine
 
 
Ma quella e' appunto una funzione di debug; e' fatta apposta per iniettare del
contenuto su stdout... Li', l'errore (architetturale) sarebbe pensare di AVERE
l'accesso al suo output, non di non averlo.
 
Header(), la funzione (quale che sia) che manda l'output finale al browser, e,
ovviamente, cose come crash(), var_dump(), ecc., l'output possono averlo... o,
addirittura, devono.


 addirittura, devono.
 
certo ci sono sempre le eccezioni
 

non ho capito il gioco di parole :)
 
Non e' un gioco di parole... ero io che mi ero fumato la corda e stavo
probabilmente pensando in Klingon. Scusami.
 
Intendevo mettere a confronto l'avere accesso all'output:
 
	function eeeeh() {
		return "puppa";
	}
 
rispetto ad avere l'output:
 
	function eeeeh() {
		echo "puppa";


 	}
 
ma quindi a rigor di logica la funzione debug, l'output lo deve 
restituire o lo deve visualizzare?
Faccio un po' di fatica a comprenderti ;)
 
Ad esempio debug_backtrace() lo restituisce

 Quindi i geni che hanno scritto Doctrine non sono poi così geni :-P
 
~~~
Caution: You are browsing the legacy 1.x part of this website.
 
This version of symfony is not maintained anymore. If some of your 
projects still use this version, consider upgrading. 
~~~
 
 
http://it.wikipedia.org/wiki/Symfony
:
 
1.4 	Novembre 2009
 
 
Stai studiando codice di 5 anni fa...
 
Oltretutto, è codice per fare testing di un sistema headless. Scrivere su 
stdout in questo caso è il modo migliore, perché se hai un monitor per i 
test, intercetta stdout, e se non ce l'hai, l'output viene, nel 99.9% dei 
casi, rediretto (per esempio cron e at te lo mandano per email)
 
Bye.

 ha scritto:

a questo punto però mi chiedo quando sia il caso di usare lo
 stream, e quando invece stampare i dati su appositi file di
 log?
-- 
 
 
----Android NewsGroup Reader----
http://usenet.sinaapp.com/
 

 
 
Cosa intendi per monitor di test?
-- 

Faccio un po' di fatica a comprenderti ;)
 
Eh, probabilmente dovrei dormire di piu' ;-)


 Cosa intendi per monitor di test?
 
Roba tipo Jenkins o Travis. :)
 
Bye.

  stream, e quando invece stampare i dati su appositi file di log?
 
Un framework non dovrebbe mai scrivere di sua iniziativa su un file o su 
stdout/stderr.
 
Un'applicazione (che usi un framework o meno) può fare quello che vuole, 
dipende dalle esigenze del progetto.
 
Ma generalmente si tende a costruire una libreria o un framework "sotto" 
l'applicazione, usando pezzi riutilizzabili.
 
A quel punto il tuo logger dovrà accettare o un nome di file dove scrivere 
i log (ma risulterà limitato) o uno stream (così può scrivere anche in 
rete o a schermo). Oppure implementare un componente per ogni output e 
l'applicazione deciderà quale usare.
 
Bye.

 l'applicazione deciderà quale usare.
 
limitato in che senso?

 limitato in che senso?
 
Nel senso che se gli passi solo un nome di file può scrivere solo su un 
file. Se hai un logserver, un'applicazione distribuita su più server, la 
necessità di loggare su db, ecc. ecc. non lo puoi fare.
 
Bye.
 


 
logserver?
Si tratta di una struttura hardware o soft?
 

 Si tratta di una struttura hardware o soft?
 
software