Le specifiche PSR-7 descrivono una proposta di standardizzazione delle interfacce per i messaggi HTTP.
Come sappiamo, il protocollo HTTP, attraverso le specifiche redatte dal W3C, definisce una serie di regole di comunicazione che vengono implementate dalle applicazioni client e server che lo adottano.
A prima vista niente di nuovo sotto il Sole dunque, ma cerchiamo insieme di comprendere l’insieme di problematiche che sono al centro di questo nuovo dibattito che riguarda gli standard di codifica del linguaggio PHP.
Controllare il tasso di coverage dei test è un’attività frequente tra gli sviluppatori.
Numerosi sono i fattori che hanno reso il code coverage popolare:
- è una metrica facile da comprendere;
- si misura senza difficoltà;
- è oggettiva e imparziale;
- è universale (applicabile a tutti i paradigmi di programmazione).
Ma al di là di questi vantaggi, possiamo affermare che una test suite con un’alta percentuale di coverage sia realmente efficace?
Quando un test è efficace?
Una test suite è considerata efficace se consente di rilevare una grande quantità di failure; d’altronde, ciò è proprio la finalità ultima del software testing.
La massima efficacia è realizzabile solo applicando testing esaustivo ma, siccome ciò è spesso impraticabile, ci si accontenta di test più semplici con un’efficacia inferiore.
È importante notare che, a differenza del coverage, il livello d’efficacia viene stabilito soggettivamente dallo sviluppatore.
A ben più di uno sviluppatore sarà capitato di incappare nel comune errore MySQL server has gone away!, magari seguito da un eccezione lanciata da una delle classi PDO, come ad esempio PDOStatement::execute(): Error reading result set’s header.
Nella maggior parte dei casi, quando questo avviene in ambiente PHP, siamo connessi in maniera persistente (per fortuna!) ed a causa di una esecuzione troppo lunga, la connessione col server MySQL va in timeout. Lunghi tasks in batch, chiamate a ws non particolarmente rapidi, carichi elevati del server, sono alcuni degli scenari possibili.
Gli operatori ternari sono diffusi in molti linguaggi di programmazione e permettono di esprimire con una sintassi breve logiche condizionali. Per utilizzarli propriamente in PHP è però necessario conoscerne il comportamento.
Vediamo un esempio
var_dump(true ? 'a' : 'b' ? 'c' : 'd'); // OUTPUT: string(1) "c"
Se state pensando che il risultato di questa espressione sia ovvio, vediamo cosa succede ad esempio in javascript
console.log(true ? 'a' : 'b' ? 'c' : 'd'); // OUTPUT: a
Bene, mentre in PHP il risultato è dato da:
- true è vero, ritorna a
- a castato a bool è vero, stampa c
In javascript invece il ragionamento è diverso:
PHP, fin dalla versione 5.2.0, introduce gli oggetti \DateTime per operare con date ed intervalli, fornendo finalmente un alternativa alle vecchie funzioni procedurali.
Recentemente mi sono reso conto di uno strano comportamento che si verifica quando vengono chiamate var_dump, print_r, var_export o debug_zval_dump su un istanza di \DateTime.
Considerando il seguente codice e il suo output:
$date = new \DateTime();
var_dump(isset($date->date)); // OUTPUT: bool(false)
ci rendiamo conto del fatto che non esiste alcuna proprietà $date all’interno dell’istanza di \DateTime.
