Test automatizzati

[Flavio93Zena]

Sarebbe possibile introdurne? In cosa consisterebbero? In script che spammano funzioni a random? Sarebbe possibile testare tutti i casi limite di un qualcosa in questo modo? Se così fosse non sovraccaricherebbe il server in qualche modo?

*vogliocapire*

EDIT: ho un treno da prendere alle 11:23 quindi se non rispondo sapete perchè torno verso le 5... Forse xD

[emanuele]

Iniziamo con un po' di generico che ti puoi leggere in viaggio:
http://it.wikipedia.org/wiki/Unit_testing

* emanuele va a finire un paio di altre cose.

[emanuele]

I test automatici non sono qualcosa che fai "in produzione", ma qualcosa che fai durante lo sviluppo. Ti servono per svariati motivi, tra cui:
1) ridurre il rischio di introdurre bug,
2) documentare il codice,
3) ti forza a seguire "buone pratiche".

Il punto 2 può sembrare un po' un controsenso, ma sì, scrivere test è un modo di documentare il codice. Prendiamo un esempio: SMF è pieno di... pezzetti di codice che fanno "qualcosa", ed ogni volta che devi toccare uno di quei pezzi (e magari non sai nemmeno di stare modificando un pezzo critico) rischia di rompersi qualcosa altrove. Questo perché il codice si tiene in piedi sulle idee "estemporanee" che ognuno degli sviluppatori ha avuto mentre toccavano un certo punto del codice. Esempio: $_REQUEST['start'] in Display.php, e usata, assegnata "by ref", passata "by ref", modificata, ecc. in quasi tutto il file. Ogni volta che la tocchi rischi di rompere una delle condizioni successive ed introdurre un bug. Applicare "unit testing" o anche test automatizzati (che se vogliamo fare i pignoli son due cose diverse) può servire ad esempio, ad evitare che una modifica ad un pezzo del codice che gestisce $_REQUEST['start'] in Display.php possa introdurre dei bug.

Ed ora, dato che un esempio vale più di mille parole, la mia esperienza con ElkArte.
In una fase iniziale di ElkArte abbiamo iniziato ad introdurre semplici test, sia unit testing (anche se fare unit testing su questo codice non è ancora facile), sia "functional testing" (dopo ci torno).
Se voi guardare il repository di ElkArte:
https://github.com/elkarte/Elkarte/
c'è una directory "tests", al cui interno ci sono svariate directory che ricordano la struttura di Elk e svariati file (ancora pochi purtroppo), ognuno dei quali si occupa di eseguire una certa serie di test.
Ad esempio:
https://github.com/elkarte/Elkarte/blob/development/tests/sources/FilesTest.php
questo file, non va altro che prendere ogni file php di Elk e verificare che non abbia errori di sintassi. A tutti può scappare una parentesi, ma evitare che questa parentesi causi problemi al codice è meglio scoprirlo *prima* che il codice venga importato nel repository "principale" da cui poi vengono gestite le release.

I test in teoria dovrebbero essere eseguiti prima di ogni commit, ma siccome al momento Elk non è ancora strutturato per gestire al meglio lo unit testing, sfruttiamo servizi esterni che eseguono i test prima che il codice venga incluso:
https://github.com/elkarte/Elkarte/pulls
queste sono le richieste di inclusione di codice, se guardate di fianco all'oggetto, vedrete delle spunte verdi, o delle croci rosse, cliccandoci sopra vedrete maggiori dettagli.
Per Elk usiamo due sistemi: scrutinizer-ci e travis-ci.
Il primo effettua un'analisi del codice alla ricerca di potenziali bug, problemi di documentazione, incongruenze, problemi di complessità/design, ecc. Il secondo si occupa di eseguire i test.
Al momento scrutinizer segnala errori perché cancella i dati dopo un mese, e quei particolari test son stati fatti tempo fa e mai inclusi perché ancora in lavorazione (mi son dovuto concentrare su altro e non ho potuto finire questi). Quindi andiamo direttamente a pescare un test di travis-ci:
https://github.com/elkarte/Elkarte/pull/1889
questo è particolarmente interessante per spiegare come lo unit testing ed il funzional testing possono aiutare.
ElkArte viene testato su 3 versioni di PHP (5.3, 5.4, 5.5) e sia con MySQL sia con PostgreSQL.

Piccolo excursus, è l'ora di spiegare cosa sono i "functional tests".
Il "functional testing" è inteso (in questo contesto, perché in generale ha una definizione piuttosto rigorosa) come il testare "una funzionalità" dal punto di vista dell'utente, non dal punto di vista del codice.
In ElkArte consideriamo "funzional testing" l'installare ElkArte ed eseguire alcune operazioni per verificare che se ad esempio clicchiamo sul pulsante "registra", ElkArte ci presenta la pagina di registrazione e non quella di login.
I vari test li eseguiamo utilizzando Selenium.
Excursus chiuso.

Allora, in quel test che ho linkato in precedenza, TE ha introdotto la cosiddetta "two factors authentication", cioè l'utilizzo di "due strumenti" per loggarsi, quindi non più solo username e password, ma username, password ed un codice univoco ed unico inviato ad un terzo dispositivo (solitamente un cellulare).
Una delle colonne che aveva usato si chiamava "2fa_secret", ma in PostgreSQL non si possono creare colonne il cui nome inizia con un numero. Ora, un conoscitore di Postgre sicuramente lo sapeva, ma la cosa ci è sfuggita. Ma non è sfuggita a PostgreSQL, così quando il test è stato eseguito è risultato in un errore, l'errore è stato riportato, ed la "build" è risultata fallita, costringendoci ad indagare il perché i test con Postgre non funzionassero. Abbiamo individuato l'errore e l'abbiamo corretto il codice prima ancora che venisse integrato in ElkArte.
Se qualcosa di simile fosse stato fatto in SMF, il risultato sarebbe stato: includi la funzionalità, rilascia la versione, aspetta che qualcuno installi usando Postgre come DBMS, aspetta che qualcuno che usa Postgre abiliti la 2FA per scoprire che non funzionava.
ElkArte bug individuato in 30 secondi dopo che il codice è stato inviato per l'inclusione.
SMF bug scoperto dopo... tempo che è stato introdotto, modificato, reso più complesso e magari anche rilasciato.

Detto questo, ElkArte usa ancora solo un piccolissimo set di test, attualmente la "code coverage" (volgarmente detto la percentuale di codice coperta da unit testing) si aggira attorno al 4/5%, una misura infima, ma che è già stata utile svariate volte nell'individuare bug anche subdoli. Ovviamente dobbiamo migliorare. Idealmente, un giorno, ogni nuova classe introdotta, sarà accompagnata da un set completo di test.

Ultima cosa, prerequisito per un corretto, "facile" ed utile unit testing è la semplicità del codice. Ogni funzione deve fare poco, ma farlo bene. Più cose una funzione fa, più condizioni esistono, più legami con altre funzioni ci sono, più testare diventa complesso e meno significativo. Per questo, testare SMF (ed ancora anche ElkArte) è complicato e richiede molti sforzi.
Però se non si inizia non si andrà mai da nessuna parte.