 Grazie. Allora parliamo di qualità di software in a plugin di WordPress. Non necessariamente di WordPress, perché comunque la ci sarebbe probabilmente da parlare un po' di più. Però io mi sono immaginato una situazione che qualcuno ha una piccola azienda, un sviluppatore passionato open source, una persona comunque che a un certo punto si trova con un plugin che usa magari privatamente nel suo blog o lo vuole mettere open source, mettere il suo WordPress plugin sul directory. E si prendono ovviamente un impegno abbastanza importante e a un certo punto si trova con dei piccoli problemi che abbiamo tutti, quei problemi di qualità nel nostro software e della domanda che cosa possiamo fare. Quindi voglio parlare di questo che mi sia un tema interessante. Prima magari vi dico chi sono io, purtroppo mi ha già preso parte della mia prima slide. Però io lavoro per MotoK, sono un principal engineer, parlare di qualità di software, di testing, di far mentoring per sviluppatori e quello che faccio tutti i giorni. E quindi non è un caso che oggi parlo di questa parte dello sviluppo, però sono anche io uno sviluppatore open source, ho fatto un paio di plugin e sono un mitapogenizer enthusiastio di quello che vuoi. E così avete più o meno il quadro di chi sono io e oggi, purtroppo abbiamo delle slide vecchie. Allora, le cose che possiamo fare per rendere l'idea di alzare la qualità del software e soprattutto fare unit testing, che quello sarebbe sempre il mio primo consiglio, qualsiasi persona che viene da me e dice cosa posso fare, cominciamo con unit testing. Il caso ideal è che cominciamo già dall'inizio con unit testing e lo facciamo molto spesso. Adesso potrebbe essere anche di un subito potrebbe arrivare con la domanda, ma che cos'è unit testing alla fine? Allora, se io sviluppo software, teniamo una classe, una funzione, quello che è una unit e io con la mia funzionalità, io faccio delle promesse. Se tu usi la mia funzionalità a un certo modo, si comporta da così. Questa è una promessa che posso fare, ma la posso anche verificare e questo è unit testing, perché comunque io posso testare con qualsiasi condizione, entro nella mia funzionalità e faccio vedere che la mia promessa sono buona, poi prendo bene. Questo è una cosa fondamentale e per questo cominciamo presto e lo facciamo spesso, che testiamo il nostro software anche nell'andale avanti. Un'altra idea è andare avanti dopo il unit testing con l'analisi del codice in un modo statico, poi parliamo un attimo di coding standard, che ci porta automaticamente sulla peer review e quality gates, che è un altro concetto che mi interessa al momento, che comunque ci porta nel mondo KPI e creiamo magari idea metrica che possono verificare quello che ci interessa. Però visto che spesso sento un po' l'idea che unit testa sarebbe una cosa complicata, ma non lo è, abbiamo tutti i tool a disposizione che ci rendono la vita molto facile. Potendo attenzione che usiamo composa nel nostro sviluppo e potendo l'idea che possiamo installare un PHP unit, che ci dà tutta la infrastruttura che ci serve per fare il test. Adesso, se torniamo un po' sulla idea del possiamo testare il nostro unit in un modo che non dobbiamo necessariamente avere WordPress installato, ci servono anche framework che possono moccare la funzionalità e per questo io al momento favorisco Brain Monkey, perché Brain Monkey? Brain Monkey fa una cosa che proprio entra in questa funzionalità che ci dà possibilità di dire quando tu incontro una funzionalità nel tuo test, che non conosci, quindi non ho installato WordPress per il mio plugin per esempio. Il mio plugin durante il test incontro la funzionalità che sono magari funzionalità di WordPress, io posso dire quando tu, when, vedi una funzionalità cosa fai, mi dai un valore indietro, steps fa una cosa simile, io posso anche fare un gruppo, definire un gruppo di funzionalità, dire se tu vedi questa funzionalità, rispondi sempre così e io posso creare le situazioni che posso fare entrare nel mio albero della funzionalità in ogni caso e dare la risposta che ho, come ho detto, promesso. Con Expect, la cosa diventa un po' più interessante perché posso anche dire quante volte vedi una funzionalità o quando tu entri in una funzionalità, vedi una funzione di WordPress, che cosa ti aspetti come argomento per entrare in questa funzionalità? Brain Monkey vena anche con una serie di funzionalità che sono già predefinite, quindi rendono la mia vita un po' più facile e la cosa molto interessante di Brain Monkey perché mi pare che a un momento uno dei pochi framework funziona veramente sul testing dei hook in WordPress. Poi sono dei filtri della action, io posso verificare se entro in una funzionalità mi aspetto che viene aggiunto una azione, entro in una funzionalità mi aspetto che viene applicato un filtro. Questo cosa posso fare con Brain Monkey. Abbiamo magari la situazione che possiamo verificare la nostra funzionalità e le promesse che abbiamo fatto, però questo non ci dice che abbiamo scritto un buon codice perché abbiamo solo verificato che la nostra funzionalità fa quello che deve fare. Ci sono altri prodotti, probabilmente qualcuno usa da Psalm o prodotti simili. Io personalmente mi trovo bene con PHP Stan che c'è anche un plugin di WordPress che automaticamente verifica anche cose che sono normali nel mondo WordPress. Un esempio di una mia funzionalità di un MVP che mi dice chiaramente che fa tornare un valore buon per una action che non mi aspettavo, una cosa così, che tu in ogni test potresti mai verificare se questo è un problema o no, perché potresti dire io mi aspetto un titolo di un buon. Quindi questa parte di analizzare lo codice in modo statico, secondo me va oltre il unit testing, però secondo me non ha nessun valore se non hai fatto unit testing prima, dopo probabilmente il PHP Stan sarebbe il mio prossimo step. Potrei anche installare ovviamente un code sniffer, però c'è anche un progetto molto interessante per WordPress, però personalmente userei PHP Stan e qua i coding standard che sono importanti. La farei fare dal id, perché comunque anche la diversi id danno giare plugin che ti danno la possibilità di fornire un codice che è ben formatato e da magari anche segnali quando c'è un po' di, quando ci sono problemi di legibilità o di qualcosa che è inaspettato. I coding standard, io credo che comunque, magari sono non in migliora di la definizione aktuale dei coding standard che abbiamo in WordPress, magari non sono tutti d'accordo con la definizione o come sono fatto in momento, dico solo che io come esempio, io da condition che magari uno potrebbe essere d'accordo o no, ma ci sono. Quindi c'è una specie di standard che posso dare anche certezza a altri sviluppatori se mi vogliono fare le contribuzioni e posso anche essere sicuro che loro, comunque, trovano un codice che per loro è legibile, che secondo me è una cosa importante per comunque avere una possibilità come avere una contribui. Perché se io ho più, quindi, colleghi programmatori che conosco, contributori sul mio plugin open source, che magari incontrano una situazione dove il codice non è formatato bene o ha dei problemi chiaramente di formatazione, quindi qualsiasi cosa che fanno magari al mio codice risulta in un code change, quindi anche cosa piccolina, qualcuno fa una indention e automaticamente tutto il mio codice è cambiato, che non va bene. Quindi il code review e il standard vanno, come si dice, hand-in-hand, vanno insieme. E sulla code review sicuramente se si lavora un team, avere una checklist per la code review è una cosa importante, anche quando uno sviluppa da solo, che potrebbe avere comunque anche metrico, tipo voglio almeno rimanere nella code coverage che avevo prima, quindi la copertura dei test che avevo prima, magari potrebbe essere una metrica. Cod review è anche un modo molto interessante per imparare o insegnare. Lo vedo molto nell'azienda, che discussioni che si aprono sono interessanti, che ti portano un qualcosa che magari dici a un certo punto, ok, non sapevo, avevo imparato qualcosa, o poi dare anche input interessante per altre persone. Magari una metrica può essere anche di non andare oltre di 200 rig, un numero che è messo così, non potrebbe anche dire 400 o quello che, però vuol solo dire che se tu fai code review, magari sono pezzi piccoli, potrebbe essere una cosa fattibile e sicuramente porta anche più qualità che dà l'input. E se puoi automatizzare questa parte, sarebbe anche un bene e sicuramente nella prossima slide. Vediamo anche un attimo questa parte. Perché, come detto, se parliamo della code coverage, della copertura del test, arriviamo anche a un certo punto ai quality gates. Questo è un concetto in realtà del QA, dei QA Specialist che controllano la qualità del software. E loro hanno spesso questo concetto dei quality gates. Però se ci pensiamo un attimo questa cosa di che recording standards, fare code review eccetera, sono già quality gates. Sono punti dove io decido se voglio andare avanti o no con un cambiamento nel mio software. E questa cosa, tipo anche di finire KPI, percentuale della copertura, questa parte può essere anche automatizzata. Se prendiamo, per esempio, oppola, adesso devo andare a secco, così perché cambiamenti non sono entrati nella slide. Se usiamo, per esempio, a Github, avevo la possibilità di usare le action. Possiamo creare una situazione che qualsiasi poi il request al mio software. Esego automaticamente la copertura, esegue le unitest, crea un file per capire quanto è la copertura e si può fermare a questo punto se tu non arrivi a una certa percentuale o i test falliscono. Anche questo ovviamente è un quality gate perché alla fine non può andare avanti perché risulta automaticamente una cosa fallita che non vogliamo andare in produzione. Ho creato un paio di, messo il link ai vari software anche PHP 10, Core Instance, eccetera, eccetera, così si può vedere questa cosa anche dopo perché i slide prendono comunque linkati nello speech e già tutto. Altra due slide, però non sono entrate nei change. Però se avete domande. Prima di tutto. Grazie. Qualcosa da noi, WordCamp per te. Allora se non mi sbaglio abbiamo detto solo domande difficili. Allora domande. Grazie mille. Luca hai fatto lo speech solo per te. Purtroppo si hai visto quality gates non passati. Hai parlato di unit testing, ti volevo chiedere se hai mai usato snapshot testing per PHP e il fuzzy testing. Allora non ho usato snapshot testing, ma usiamo anche del smoke testing. Questa è una cosa che facciamo spesso volentieri che creiamo anche situazioni di cambiamento voluto al software, di vedere se il nostro software si comporta ancora così. La ragione per questo è abbiamo un prodotto che magari deve essere installato in diverse condizioni di installazioni clienti che hanno magari un plugin che potrebbe essere una dipendenza per noi e abbiamo bisogno di chatets come si comporta il nostro software in questi casi, questi test facciamo anche. Però sono più nella fase end to end e non proprio nel unit testing. Ok, altre domande. Ciao. Considerando l'evoluzione che sta subendo l'ecosistema di WordPress sempre verso più il JavaScript, hai già avuto modo di testare un nuovo ambiente di test che non sia prettamente incentrato su PHP? Sì, noi abbiamo dei, nei nostri prodotti molto ok, abbiamo dei test per JavaScript. Usiamo Jest e funziona bene. Possiamo anche, perché usiamo alla fine un prodotto che si chiama su una cloud mandare già segnali verso questa piattaforma per capire un po' come ho detto i quality gates si corrispondono a quello che ci aspettiamo per JavaScript e per PHP in uno stesso istante. Sicuramente ci sono altri prodotti. Mi piacerebbe anche sentire la voce e usare altri prodotti che possono essere uno spunto anche per noi. Ok, altre? No. Ok, allora ancora, grazie Dennis di essere venuto all'ultimo momento. Non mi hai fatto una domanda. Grazie. Grazie.