Esporta una tabella in formato array di php

<?php

/**
* Export to PHP Array plugin for PHPMyAdmin
* @author Geoffray Warnants
* @version 0.2b
*/

//
// Database “PROVA”
//

// PROVA.Classificazioni
$Classificazioni = array(
array(‘id’=>1,’Nome’=>’Una Stella’),
array(‘id’=>2,’Nome’=>’Due Stelle’),
array(‘id’=>3,’Nome’=>’Tre Stelle’),
array(‘id’=>4,’Nome’=>’Quattro Stelle’),
array(‘id’=>5,’Nome’=>’Cinque Stelle’)
);

Ah! Sono stato proprio distratto. Adesso però vorrei capire se qualcuno si è divertito con questa features e l’ha usata per i suoi scopi malvagi. Magari può suggerirmi qualche buon utilizzo.

Cosa significa la sigla TDD?

Significa Test Driven Development ovvero sviluppo guidato dal testing.

Più precisamente?

Significa che per sviluppare un software, si scrivono prima i test, e poi il codice vero e proprio. Per dirla in un modo più amichevole: sapendo che cosa deve fare una applicazione, noi dobbiamo prima scrivere del codice che si basa sulle specifiche di un progetto e che afferma che ciascun metodo deve risultare determinati valori.

Troppo complicato? Proviamo con un esempio semplice: scriviamo i test per implementare il metodo somma.

Immaginiamo di dover implementare una calcolatrice e di avere un metodo somma($addendoUno,$addendoDue); Va da se che somma(1,3) dovrà restituire 4. E’ un requisito del metodo. Bene, prima di implementare una qualsiasi riga di codice per la somma, scriviamo il test che controlla che dati due precisi valori, restituisca un terzo nel modo corretto. Scriviamo diversi test. Molto bene: i requisiti della nostra funzione somma, sono che la somma funzioni. (lol)

Abbiamo scritto i test, ed ora?

Ora lanciamo i test.

I test falliranno tutti, perchè non abbiamo ancora scritto nessun codice. Quindi procediamo e scriviamo il nostro metodo.

Testiamo il codice!

Adesso che abbiamo implementato il codice, lo possiamo testare e se il metodo somma funziona correttamente, farà andare a buon fine tutti i test. Bene! Il codice che abbiamo creato è stato testato e funziona.

Perchè ho scritto un test?

I testi si possono scrivere per varie ragioni ed ora elenco alcuni vantaggi che ho visto fino a questo momento:

• è facile intuire, che dicendo al codice come deve comportarsi quando è corretto (scrivere un test) ci porterà a ridurre i bug e, per esempio, a non avere errori di logica nella programmazione.
• possiamo fare refactoring e ritestare tutto il codice. Se i test vanno a buon fine, non dobbiamo chiederci se ci sono errori “in giro”. Il codice funziona bene come prima del nostro operato quindi siamo felici e tranquilli =). Abbiamo fatto un buon lavoro.
• vengono testate le singole funzionalità, o unità (unità di test appunto) ed si cicla in questo modo: si decide la funzionalità, si scrive il test, si scrive il codice e lo si modifica se e fino a quando il test non è soddisfatto. Da quel momento in poi, non dovremo più preoccuparci di nulla.
• ogni test è documentazione, in quanto spiega il funzionamento di ogni piccola unità di codice. Talvolta può persino sostituire la documentazione stessa.

Molto bene, non entro oltre nel dettaglio anche perchè se devo essere sincero, solo oggi ho realizzato una classe usando il TDD. In particolare ho pensato di scrivere del codice oop per realizzare una pagina html5 di base. Ho ragionato in questo modo: so come è fatto un documento scritto in HTML5, implemento dei test in modo che mi vengano restituite delle parti di codice nel modo esatto che desidero. Implemento il codice e via di seguito.

Ancora più semplicemente, vediamo gli steps:

1. scrivo un test
2. faccio fallire il test (per assicurarmi che la funzionalità non è stata implementata)
3. metto mano al codice in produzione fino a che il test non ha esito positivo
4. torno al passo 1

Ma scrivere un test dopo aver scritto il codice di produzione non è uguale?

Di primo acchitto potrebbe sembrare. Difatti, però, scriveremmo dei test influenzati dal codice, e di conseguenza non sarebbero test rivolti allo scopo dell’applicazione ma del codice appena scritto. Per ora il post lo concludo qui. Spero che sia utile a qualche lettore …

Veniamo al dunque e partiamo con un’immgine eloquente, causata dalla corretta installazione di PHPUnit. Decisamente molto più semplice. Se avete letto il post precedente, non avrete bisogno di spiegazioni:

Corretta installazione di PHPUnit

Faccio un breve riassunto dell’accaduto:

1. Scarico XAMPP e lo installo.
2. Lancio alla rinfusa dei comandi come se stessi ancora operando con wampserver …
3. Ad un certo punto lancio “pear install phpunit/PHPUnit” e tutto funziona

In sostanza con XAMPP posso passare direttamente all’installazione di PHPUnit perchè, al contrario di wampserver, ha già PEAR installato. Molto bene. Adesso vediamo come posso usare PHPUnit per fare dei tests alle mie applicazioni php. Ne creerò una da zero, così potrete usufruire del mio sforzo =). (Speriamo che sia utile a qualcuno).

Creazione di un progetto per testare php con PHPUnit

Dopo aver creato il progetto, ho creato una classe “Giorni”. Questo esempio, ha uno scopo “sintattico” e non “semantico”. Non so quanto senso abbia creare una classe di questo tipo, ma lo scopo di questo post è mostrare come si fanno test con PHPUnit e non come si programma ad oggetti =). Va da se che ora vi beccate la classe più inutile della storia (occhio che nell’immagine c’è un errore: manca la keyword “function” prima di getNomeGiorno. Se non correggete questo errore, ovviamente non potrete generare l’unità di test):

Classe Inutile =)

Potevo anche evitare di programmare ad oggetti per un esempio così banale … Fatto sta che adesso arriva il bello: come creo l’unità di test per questo file? Adesso dobbiamo fare click con il tasto destro del mouse sul nostro file, quindi …

Come creare un'unità di test per una classe PHP

Con questo comando verrà generata un po’ di roba. Vi spiego: come potete notare, il nostro progetto di Netbeans contiene una cartella Source files ed una Include Path. Dopo questa operazione, avremo anche la cartella Test files. Nel frattempo, ho creato il primo test. Il test ha il compito di verificare che la classe funzioni correttamente. Mi aspetto che getNomeGiorno di 3, mi restituisca “Mercoledì”. Ho deciso che il programma deve funzionare in questo modo o comunque mi aspetto che si comporti in questo modo quindi …

Un primo test sbagliato con PHPUnit

Accidenti è sbagliato. Ovviamente l’errore era voluto. Infatti noi abbiamo chiesto il giorno numero 3 fosse Mercoledì. Il test ci segnala che getNomeGiorno non funziona correttamente. Infatti 3, per la funzione, non è la posizione ma l’indice. Andiamo subito a correggere la classe in  … ”return $this->nomi[$IndiceGiorno-1];”. La posizione 3, infatti, è l’indice 2. Gli umani contano da uno mentre gli array di php partono da 0. Dopo aver riscritto il codice, rilanciamo il test premento Alt-F6. Ecco il risultato:

Esempio di un test corretto con PHPUnit e Netbeans

Il nostro programma è stato testato correttamente. Ovviamente l’argomento non si estingue qui. Ma sicuramente può dare spunti su come iniziare a programmare partendo dai test. Non ne so più di quello che leggete qui, spero però che sia abbastanza per aiutare qualcuno in difficoltà a partire. =)

Buoni test a tutti.

Divido l’articolo in due parti: nella prima la mia sfida sarà rivolta a PEAR e Windows. Nella seconda parte, il nemico da affrontare si chiamerà semplicemente PHPUnit.

Parte prima: installiamo PEAR con wampserver.

Una suite di test per php che si integra con Netbeans è PHPUnit. Però PHPUnit ha bisogno di PEAR. Ed ecco lo smacco. Premetto che ho windows in questo momento percui sono andato sul sito di PHPUnit, e da li alla pagina di installazione. PHPUnit ha bisogno di PEAR per essere installato. Molto bene… installiamo PEAR.

Come si installa PEAR? Beh, se andiamo nel blog ufficiale di PEAR, dove mi dicono che devo digitare a riga di comando “go-pear.bat”. Ovviamente non funziona nulla. Al che cerco in giro per la rete una marea di soluzioni diverse ma nessuna efficace. Mi suggeriscono di andare a modificare le path di windows. Non sapendo bene che cosa dovevo fare… ho semplicemente constato che il comando php -d phar.require_hash=0 go-pear.phar non poteva trovare go-pear.phar dalla cartella di php per la banale ragione che si trova dentro la cartella PEAR.

Quindi per riuscire ad installare PEAR, ho modificato leggermente quel comando che tutti segnalavano in php -d phar.require_hash=0 PEAR/go-pear.phar da dentro la cartella di php [nel mio caso c:\wamp\bin\php\php5.3.0]. Ho anche modificato go-pear.bat in questo modo:

@ECHO OFF
set PHP_BIN=c:\wamp\bin\php\php5.3.0\php.exe
%PHP_BIN% -d output_buffering=0 c:\wamp\bin\php\php5.3.0\PEAR\go-pear.phar
pause


Finalmente mi ha richiesto se volevo installare PEAR. E certo che lo voglio installare. Poi ho fatto l’installazione in locale. E poi ho proseguito dicendo si a tutto da bravo informatico. =) Non fate come me insomma. Adesso incrocio le dita e spero che l’installazione di PHPUnit sia più fortunata.

Parte seconda: installiamo PHPUnit.

Cerco di seguire le indicazioni che mi segnala questo blog che pare fare al caso mio: Installare PHPUnit su WAMP. Ovviamente non è andato a buon fine. In particolare quel blog dice di lanciare PEAR_ENV.reg ma la cosa non piace al mio pc. Poco male, non è che mi freghi più di tanto che pear si possa usare ovunque (o almeno spero).

Lancio il comando successivo: pear channel-discover pear.phpunit.de. Molto bene, canale registrato. Ed ora… pear install phpunit/PHPUnit. Secondo voi? Secondo voi niente … non è andato:

Errore durante l'installazione di PHPUnit

Ma perchè?!?!?! Ho cercato in giro per internet “parse error in Unknown on line 14″. 3 link sono usciti dai risultati di Google, andiamo un pochino a vedere che cosa ci dicono. Ah! sia chiaro. A parte il primo blocco di PEAR… quello che state leggendo lo scrivo mentre “agisco”. Pensate: il secondo risultato è di una pagina di supporto a tutt’altro: un errore sulle stringhe json con jQuery. Fatto stà… che in fondo alla pagina in questione ci sono dei thread simili e la vedo questo “PEAR-BUG] Bug #16596 [Opn]: parse error in Unknown on line 14″ ed ho quasi paura a cliccare. Molto bene… quel link porta ad una risposta che dice:

“This happens when running PEAR commands from the Windows
Command Prompt. It seems like the dialog box is being produced by the
Windows OS, perhaps at the behest of PHP or pear.bat.”

Traduco:

Questo accade quando si eseguono i comandi PEAR dal Prompt dei Comandi di Windows. Sembra che la finestra di dialogo venga prodotta da Windows, magari su richiesta di PHP o di pear.bat

Cioè, abbiamo a che fare con un genio. =). Vabè, per non saper ne leggere ne scrivere… proviamo a ficcare il naso dentro pear.bat. Mannaggia… nulla di chiaro. A riga 14 non c’è nulla di interessante. Faccio più attenzione agli errori che mi mostra il Prompt dei comandi e … sorpresa:

phpunit/PHPUnit requires PEAR Installer (version >= 1.8.1), installed version is
1.8.0

Per questo post, PHPUnit/Wamp/PEAR 1 demo 0. Ovvero vado a dormire. Domani è un altro giorno! Spero di non metterci troppo a scrivere un POST “FINALE” che sveli l’arcano sull’installazione di PHPUnit su Windows Vista.