From 444377e509a59667421d982cdb8ad2ab01e9cef5 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Fri, 6 Oct 2023 05:42:00 +0200 Subject: [PATCH 01/33] feat: proposta prima bozza capitolo testing --- docs/testing/README.md | 74 ++++++++++++++++++++++++++++++++++++++ docs/testing/piramide.png | Bin 0 -> 4532 bytes 2 files changed, 74 insertions(+) create mode 100644 docs/testing/README.md create mode 100644 docs/testing/piramide.png diff --git a/docs/testing/README.md b/docs/testing/README.md new file mode 100644 index 00000000..6829aa01 --- /dev/null +++ b/docs/testing/README.md @@ -0,0 +1,74 @@ +# Testing + +Il testing è una parte fondamentale di ogni progetto software. In questo capitolo vedremo come testare il nostro codice in modo efficace. + +## Piramide del testing + +Esistono diversi tipi di test, ognuno con un suo scopo ben preciso. Vediamoli brevemente: + +- **Unit test**: testano una singola unità di codice (una funzione, un metodo, una classe, un modulo, ecc.). Sono i test più semplici da scrivere e da eseguire, ma non sono sufficienti per garantire la qualità del software. +- **Integration test**: testano il comportamento di più unità di codice quando vengono integrate tra loro. Sono più complessi da scrivere e da eseguire rispetto ai test di unità, ma sono più efficaci per garantire la qualità del software. +- **End-to-end test**: testano il comportamento di un'intera applicazione, simulando l'interazione di un utente con l'applicazione. Sono i test più complessi da scrivere e da eseguire, ma sono i più efficaci per garantire la qualità del software. + +Nessuno di questi test esclude l'altro, e chiunque voglia scrivere del codice di qualità dovrebbe scrivere tutti e tre i tipi di test. + +Solitamente i test di unità vengono eseguiti più frequentemente rispetto agli altri tipi di test, in quanto sono più veloci da eseguire. I test di integrazione e gli end-to-end test vengono eseguiti meno frequentemente, ad esempio durante il processo di rilascio del software. + +Si fa spesso riferimento alla piramide del testing, che rappresenta la proporzione tra i diversi tipi di test: +Piramide del testing + +### Unit test + +Gli unit test sono i test più semplici da scrivere e da eseguire. Il loro scopo è testare una singola unità di codice (una funzione, un metodo, una classe, un modulo, ecc.). Per esempio, se abbiamo una funzione che calcola il fattoriale di un numero, possiamo scrivere un test per verificare che la funzione calcoli correttamente il fattoriale di un numero. + +### Integration test + +Gli integration test sono più complessi da scrivere e da eseguire rispetto agli unit test. Il loro scopo è testare il comportamento di più unità di codice quando vengono integrate tra loro. Per esempio, se abbiamo una serie di funzioni che permettono di verificare se un processo di transazione bancaria è andato a buon fine, possiamo scrivere un test per verificare che le funzioni agiscano assieme correttamente. + +### End-to-end test + +Gli end-to-end test sono i test più complessi da scrivere e da eseguire. Il loro scopo è testare il comportamento di un'intera applicazione, simulando l'interazione di un utente con l'applicazione. Per esempio, se abbiamo un'applicazione che permette di gestire un conto corrente bancario, possiamo scrivere un test per verificare che l'applicazione permetta di effettuare il login, accedere alla propria area personale, visualizzare il saldo del conto corrente, effettuare un bonifico. + +## Tipologie di test + +Esistono diverse tipologie di test, ognuna con un suo scopo ben preciso. Vediamole brevemente: + +- **Functional testing**: Il test funzionale è un tipo di test in cui il target sono le specifiche funzionali. Il sistema viene infatti testato rispetto ai requisiti funzionali, garantendo che questi siano adeguatamente soddisfatti dall'applicazione. +- **Performance testing**: Il test di performance è un tipo di test in cui il target è la performance del sistema. Il sistema viene infatti testato rispetto ai requisiti di performance, garantendo che questi siano adeguatamente soddisfatti dall'applicazione. +- **Usability testing**: Il test di usabilità è un tipo di test in cui il target è l'usabilità del sistema. Il sistema viene infatti testato rispetto ai requisiti di usabilità, garantendo che questi siano adeguatamente soddisfatti dall'applicazione. +- **Security testing**: Il test di sicurezza è un tipo di test in cui il target è la sicurezza del sistema. Il sistema viene infatti testato rispetto ai requisiti di sicurezza, garantendo che questi siano adeguatamente soddisfatti dall'applicazione. +- **Regression testing**: Il test di regressione è un tipo di test in cui il target è la regressione del sistema. Il sistema viene infatti testato rispetto ai requisiti di regressione, garantendo che questi siano adeguatamente soddisfatti dall'applicazione. + +Esistono molte altre tipologie di test, come _compatibility testing_, _acceptance testing_, _exploratory testing_, ma queste sono le più comuni. + +## Tecniche di test + +Esistono tre tecniche di test, ognuna con un suo scopo ben preciso. Vediamole brevemente: + +- **Black-box testing**: Il test _black-box_ è una tecnica di test in cui il tester non ha conoscenza dell'implementazione del sistema. +- **White-box testing**: Il test _white-box_ è una tecnica di test in cui il tester ha conoscenza dell'implementazione del sistema. +- **Grey-box testing**: Il test _grey-box_ è una tecnica di test in cui il tester ha conoscenza parziale dell'implementazione del sistema. + +Di solito queste tre tecniche vengono utilizzate per individuare eventuali falle nel sistema. + +## Metodologie di testing + +### Manual testing + +Il manual testing è una metodologia di testing in cui i test vengono eseguiti manualmente dalla figura del tester. Questo approccio ha diversi svantaggi e solitamente viene utilizzato solo per testare le funzionalità più critiche del sistema quando non è possibile automatizzare i test. + +### Automated testing + +L'automated testing è una metodologia di testing in cui i test vengono eseguiti automaticamente da un software. Questo approccio ha diversi vantaggi: **Ripetibilità**, **Riduzione dei costi**, **Riduzione dei tempi di sviluppo**. + +### Continuous testing + +Il continuous testing è una metodologia di testing in cui i test vengono eseguiti automaticamente ad ogni commit o ad ogni modifica del codice sorgente. + +### Test-driven development + +Il test-driven development (TDD) è una metodologia di sviluppo software che prevede di scrivere i test prima di scrivere il codice. + +### Behavior-driven development + +Il behavior-driven development (BDD) è una metodologia di sviluppo software che prevede di scrivere i test prima di scrivere il codice, ma con un approccio più orientato al comportamento dell'applicazione. diff --git a/docs/testing/piramide.png b/docs/testing/piramide.png new file mode 100644 index 0000000000000000000000000000000000000000..21b391997ecdb287c7c674af7924c4b43f0e0fe4 GIT binary patch literal 4532 zcmd6rS6EZs(#HdY7^DTFLJ$NY^cH#*h;NkMLT{QN1OX{ZM^p?*6RDy19;62d9n7nu z5D-BSr5UA&2+|R$C!V|S;=4cl+0Qd;X75>RU#wa4`|o%QGkx~6d}jdw0K1_93Jm}- z(uWL@U?APxmE=~Y8=wc$6bS${C9@u3nd!dJEd#VE01z$)07OOu00;C?>(_0hdEfrh5n&U`(4?hL!;)(R^D0DyEGqL9|1 zQ){y!`R8_z-)v4&D5F4gnK4b%Qd z?r|~lH;hywQcAxD@sx&%N*Od~KGlbqlw@HI7MFzZepama%?AF|=6W&o3AtCwn9Xz}LY}oq9Gmd?pwP!|y zxj{Ml8`J9#hNOnz`#o60&tpkE;KCEi=;!qySPRRb4d9cObqg`7 z-n{jMz$g|k`?_N4oj2RSk-ypG-XUT2UK-UUT>}^kYa}?I*G6vKvs^hi$-!t!^N|SF zQQ)P~1_^4t+d0b17#UG3ze?`>8!d}|C;^HNNLF-|3FtT06xZNi?S8e~Z7R07aQNu~ zp9`P0&E1)-Jhu!e3&{nhQ_j((wTKZCCEpYz_6|8rVETu}u z^S8n47FHzFw773ir_y5#Q2>5^+h>o3(i-pFRwNoY33uM8!}$;(XThk%(oMgdwa+XPafu{3yKs zg)-i16;bU!ro6C3yufaiMwqMyHZSKT1o^ya2Fh!UJ4+=xe|{!n)!f^G7S*4=i@vO5 z`N1yK+aMvyz8s~c`Q%HrG|V#xQoVccbz5w?Z%;s{LyNI>R6kuH~sN5xQU4W0`q|6xupb88^uL|r@G$0_PF z@Xge~*f;u$+UcLE&1S+xtc{kVWBxpNiDZkLwi~Dcnui}(@3=h3HuQI`oNm9g&B8%y zuJF4r(^{dMJMWD5+#z>WJP|-yP$P%hniEEWzdwB)Qw!fbPtkB6{b*V({^_MzR&TI8 zr7KV>{o@V84cJ6*7qC&9Uf!9e_q!C6XxFuF;4hiL+ex)k-B2Wx)~7#X&wzr>sGQaV zTRi6v-0zxh`gxC;BzcFJ>xj3Hv+FI^vI;_u{2a&+{P5wbAtDxk4p=EXGFFv!r&<)= z=QC{9g{qZFm6Xdm{pO4KK}-EP;m~#(b&Z0qyU{-=I!Hs{!)oXIi?;$mlt5dV z{d>ua_-iL$vI6pUha=QzueseVC{SR7y;yl&ixOUyBqq-E$jvo1vyaiZQDfo-;A4q+ zqq37~q0jA+r5&up^JPO$(ECEOJ8!QC7ALIz_(y!t)4AVPhQ+#xt><$K_{+zrmqhF> zYBX^sxLY2g?LtW1>=22(J41DkFp;mvDt9%qH~7=bJ;kW-tJkk@w?O{P4IApmVNafR z#8=s;+J&arWP?{nSo4Q}-gyg{!}7iiB}+IQr549b%t%=4m>LJQ=g<8-CKO&^m)D>;Ff*VrXGU4Y0BQLo*59D#liYO zw6^q$)nkPnW-$PwOk(0JAMYyz&^`Z^@5mkg$lPN5&*lD~&Ns&G{@{!@!>1VL+f#bf zpR~b-WAx4(sP!IWAnVO4;$t}+%E}M9N6IqYAD=|Dza2~XDk}#(`S+|Z|0M>uFPB#h z1Y*&4rIUx*b+A_hGj9X#P=9p4(AOT0n6mt`A7|H*#WWGsTkHVH2^gJ{fCuEocaW0v_@MeL6+apdprN;BfV^XcD zsLKyPt=?q6M~H`uCd1mrGi!nJ-|8`cp(T*Xl05rmsY17NTXXWRu9~P!jx<3`tp*#FH z`)@zcCeu9+Lox#FPF*aV_bokS=_i=R2WBuoTJ-Jwc2n|lhPD2j7_TqHG*AL5dyzMq z^i>A$dE>{N+j(uX4S8y`1nWolOO(r?QMMXHI*k)l(h|^epL$eSTxoC~TAtQ4XKEah z|GFjzo?&nk$CZzP$To@vusrmD7)g82k%%b6=-EY` zkTmpA&idJsZVz*7FOA`!ML zUmm^I(ag^D&O?SXcZ%`_VyL^;HCk=?{AQcC@~}PHY%31>_QzZW9*i-5X&3y}N8CYv=>i zCU9Uo@mE;A+;U1=v2C07_CZV4{kiooHeuvk(QWNAXuzj6KMQV7HKvLxwIQm z68I>v7YqY2st=GkwnQa!b>ASs5-J$!d<8rML#6Iu#VGNh68Q548@%|HCP&m8t|52X zD2uIpltuarjo+klfe|k4c{5wXW)QuVtHcQ(Dg=N*u;{e%zo)R%K^f3YJo}vysANGs zA9LxLtrRE)yS5RBl#mQp%AlEpEQK#x7&kT`C197}q3KB=OGO@N1cd}DA-BmRujIi{ zEI~LKiVxlYm_7jHxrmDQ`7dLYkb^E#_Pa%*6HDq;yJXYG@X?zF2n^etr};4m}zZntDHW6id^NvZ%J% zu+;BUw1%oJyO+=5?cTI*Xh^nDm8NhHlDiet+zahg}Rw#7aYEqHa0{grA+Yw+Rj5?k+k= z^?3RV(BBC17t<$6|MNK6>WlF|EMg8~<<&n4xKR+Kifd2RF>Z$X5eT<2;61J92j-SfUQ|?t|K1@yhXx%8>!^8jC8c;wiWpas3Fj-x= zSLH1q_|oRGwL%OnILaXP7`%c$iK^rNCM+*+Sh91IRDoJvXRfR!H9 z1%AqO{HgrC)VwbENS9*#EUKs+N6pAl|5petW!JgL8)ZS&LCPp+1dBU$o5}_yR)|^2 z+w}&ap8w=0nl2=m7TtkJW=TWu6(fmZmx4Ou6V;Px(pCPJ0Z08TRf=VFA_%z{ojWKg z-u&9rc|yiavp~g8E43?k96N?7%J<3bae-B2iFDL?lZ|v6@1<{I9K^BP7~I>qqaSlcZ$nIg z{py!it{~tcFDhnnFgo8CazHk^&ZT_^0#l3oTWwdLY8L#}H>iFa1fJ$jjlPZbR*c1@ zAPJBE3Zi#HJFUUm<{OD+{nS_SK$Th?WKiS35(<@bdxXwJoiBOx1aaJKs&R^>zeuDC z{{8s8c7KwIoB7HN|KMB0qXfyF`G63>q7Tod%~=a_{a4}^M=@zt?eWMyL9Q1%h~6l? zZ1BG#;o;T8M?7HuRyo&@RRQ|14bi}B_JMBLKzGes_uT0QpomaVlT|>-Dk7{AYMKg4 rnkwqj2!tjAf!A5i{67gker}$)u>U_{`<8_iJpo{N%?wq46@&i|4R9=i literal 0 HcmV?d00001 From 7d8af9c2a8e0044a59a502847707931ae1eaa423 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Fri, 6 Oct 2023 05:55:20 +0200 Subject: [PATCH 02/33] feat: proposta seconda bozza capitolo testing --- docs/testing/README.md | 62 ++++++++++++++++++++++++++++++++++-------- 1 file changed, 50 insertions(+), 12 deletions(-) diff --git a/docs/testing/README.md b/docs/testing/README.md index 6829aa01..aa5291b9 100644 --- a/docs/testing/README.md +++ b/docs/testing/README.md @@ -4,30 +4,68 @@ Il testing è una parte fondamentale di ogni progetto software. In questo capito ## Piramide del testing -Esistono diversi tipi di test, ognuno con un suo scopo ben preciso. Vediamoli brevemente: - -- **Unit test**: testano una singola unità di codice (una funzione, un metodo, una classe, un modulo, ecc.). Sono i test più semplici da scrivere e da eseguire, ma non sono sufficienti per garantire la qualità del software. -- **Integration test**: testano il comportamento di più unità di codice quando vengono integrate tra loro. Sono più complessi da scrivere e da eseguire rispetto ai test di unità, ma sono più efficaci per garantire la qualità del software. -- **End-to-end test**: testano il comportamento di un'intera applicazione, simulando l'interazione di un utente con l'applicazione. Sono i test più complessi da scrivere e da eseguire, ma sono i più efficaci per garantire la qualità del software. - -Nessuno di questi test esclude l'altro, e chiunque voglia scrivere del codice di qualità dovrebbe scrivere tutti e tre i tipi di test. - -Solitamente i test di unità vengono eseguiti più frequentemente rispetto agli altri tipi di test, in quanto sono più veloci da eseguire. I test di integrazione e gli end-to-end test vengono eseguiti meno frequentemente, ad esempio durante il processo di rilascio del software. +Esistono diversi tipi di test, ognuno con un suo scopo ben preciso. Si fa spesso riferimento alla piramide del testing, che rappresenta la proporzione tra i diversi tipi di test: Piramide del testing +Di seguito vedremo nel dettaglio i diversi tipi di test. + ### Unit test +Il test unitario è un processo di sviluppo software in cui le parti testabili più piccole di un'applicazione, denominate unità, vengono esaminate individualmente per verificarne il corretto funzionamento. Chi sviluppa e talvolta il personale del controllo qualità completano i test unitari durante il processo di sviluppo. Per unità solitamente si intende una funzione o una piccola serie di funzioni i cui comportamenti sono strettamente legati. + +Il punto principale è la presenza di un contesto isolato con un obiettivo. + +Non dovrebbe avere dipendenze, se presenti queste dovrebbero essere messe sotto mock quando possibile. -Gli unit test sono i test più semplici da scrivere e da eseguire. Il loro scopo è testare una singola unità di codice (una funzione, un metodo, una classe, un modulo, ecc.). Per esempio, se abbiamo una funzione che calcola il fattoriale di un numero, possiamo scrivere un test per verificare che la funzione calcoli correttamente il fattoriale di un numero. +Coverage: Solitamente gli unit test permettono di raggiungere alti livelli di code coverage proprio per via della loro granularità. + +Solitamente i problemi nati negli unit test sono più facili da correggere perché riguardano piccole porzioni di codice e molti test sono riutilizzabili anche in altri progetti se si usa codice condiviso. + +D'altro canto, se i test sono scritti male o non hanno una buona coverage, danno falsa sicurezza e non prevengono i bug, inoltre impiegano tanto tempo ad essere scritti. ### Integration test -Gli integration test sono più complessi da scrivere e da eseguire rispetto agli unit test. Il loro scopo è testare il comportamento di più unità di codice quando vengono integrate tra loro. Per esempio, se abbiamo una serie di funzioni che permettono di verificare se un processo di transazione bancaria è andato a buon fine, possiamo scrivere un test per verificare che le funzioni agiscano assieme correttamente. +Il test di integrazione è una tecnica di test del software che si concentra sul test delle interazioni e dell'integrazione tra più componenti o moduli di un sistema software. Ha lo scopo di verificare che i diversi componenti, quando combinati, funzionino correttamente e producano i risultati attesi. + +Concetti principali: +- **Scope**: Anche qui parliamo di contesto e obiettivi specifici. +- **Stubs**: Sostituti di moduli e dipendenze necessari al funzionamento dei test. +- **Spettro più ampio**: A differenza dello unit test che verifica un modulo / una funzione / un contesto specifico e ridotto, l’integration testing integra più moduli e ne testa le interdipendenze e la comunicazione. + +Tipologie di test: +- **Big-bang**: Si creano decine, centinaia, migliaia di test in base alla dimensione della codebase. Si testa tutto, tutto assieme. Solitamente il tutto viene fatto in un singolo integration test, o in pochissimi. Funziona per codebase ridotte. +- **Top-down testing**: Approccio incrementale, si parte dai moduli ad altissimo livello (Controller nel caso di un MVC) e si scende al livello più basso (Se si utilizzano i fat model si arriva anche fino a lì). Funziona per codebase grosse, iniziare è più tosta ma ha più impatto, pian piano diventa sempre più facile perché le parti "sopra" sono già state testate. +- **Bottom-up testing**: Approccio incrementale al contrario. Si parte da sotto e si va in alto. Anche qui parliamo di grosse codebase, iniziare è più facile ma ha meno impatto, proseguendo anche qui diventa sempre più facile perché l’impalcatura sotto funziona. +- **Sandwich** o **Hybrid Testing**: Combinazione dei due approcci sopra basati su un planning di priorità. + +Quando si lavora in team più o meno grandi non sempre ci si può assicurare che quanto sviluppato da una parte del team comunichi correttamente con quanto sviluppato da un’altra parte del team, questi test sono fondamentali in questi contesti, inoltre è facile individuare e correggere il comportamento di una specifica funzione (Tramite unit test o tramite semplice attenzione quando si sviluppa), più difficile è notare eventuali differenze nel modo in cui i componenti di un’applicazione interagiscono tra di loro. I test di integrazione sono OTTIMI per garantire questa sicurezza. +Infine, l’integrazione tra componenti non è solo da intendersi come "corretta comunicazione e scambio di informazioni tra le parti" ma anche "corretta gestione degli errori". In definitiva, se so che quei due componenti funzionano assieme e ho scritto correttamente i test dormo sonni tranquilli. + +D'altro canto è complesso realizzare dei test di integrazione e mantenerli nel tempo per via dell’evoluzione naturale del software su cui si lavora. + +Rispetto agli unit test, infatti, è più complicato trovare gli errori essendo più ad ampio spettro. + +Molto complesso individuare tutte le integrazioni che ha senso testare. La coverage al 100% è infatti inverosimile in progetti grossi. +Spesso realizzare questi test è più complesso perché bisogna prima avere idea della codebase sottostante, a prescindere che si lavori in TDD o meno. ### End-to-end test -Gli end-to-end test sono i test più complessi da scrivere e da eseguire. Il loro scopo è testare il comportamento di un'intera applicazione, simulando l'interazione di un utente con l'applicazione. Per esempio, se abbiamo un'applicazione che permette di gestire un conto corrente bancario, possiamo scrivere un test per verificare che l'applicazione permetta di effettuare il login, accedere alla propria area personale, visualizzare il saldo del conto corrente, effettuare un bonifico. +Il test end-to-end (E2E) è una metodologia di test del software che si concentra sul test dell'intero sistema software dall'inizio alla fine, simulando scenari del mondo reale e interazioni dell'utente. Ha lo scopo di garantire che il sistema funzioni correttamente nel suo insieme e soddisfi i requisiti aziendali desiderati. + +E qui sta il punto. I requisiti sono essenzialmente aziendali e non tecnici. + +Nei test E2E, l'intera applicazione o sistema viene testato in un modo che imita il modo in cui verrebbe utilizzato dagli utenti finali. Implica la simulazione delle interazioni dell'utente, l'inserimento dei dati e la convalida degli output previsti su più componenti, moduli e livelli del sistema. + +Anche qui parliamo di contesto e obiettivi, ma chiaramente non sono più “specifici” di per se, perché testate “specificatamente” un flusso di pagamento coinvolge centinaia di parti. Inoltre, vista la complessità di realizzare questi test, solitamente si usano strumenti che perlomeno automatizzino alcune parti del processo, come un live recording via estensione del browser. + +A differenza degli altri tipi di test, qui possiamo verificare se l’esigenza non funzionale, e quindi di business, sia rispecchiata nel comportamento della piattaforma. + +Infine, a differenza degli altri tipi di test trattati, qui vediamo all’atto pratico come i dati agiscono a 360 gradi. + +Ricreando scenari realistici, abbiamo modo di avere una sicurezza “definitiva” (tra molte virgolette) del comportamento della piattaforma. + +D'altro canto, è difficile prevedere e analizzare quante farne e cosa testare. Inoltre il test è più lungo da scrivere perché mentre per un integration test basta cambiare un flag, un e2e deve probabilmente essere riscritto perché ha flussi differenti per giungere alla stessa conclusione. ## Tipologie di test From a3a49c5e888d41765c25c9667a9b77bb58ae65c6 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Fri, 6 Oct 2023 05:56:02 +0200 Subject: [PATCH 03/33] chore: linting --- docs/testing/README.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/testing/README.md b/docs/testing/README.md index aa5291b9..bff4898a 100644 --- a/docs/testing/README.md +++ b/docs/testing/README.md @@ -12,13 +12,14 @@ Si fa spesso riferimento alla piramide del testing, che rappresenta la proporzio Di seguito vedremo nel dettaglio i diversi tipi di test. ### Unit test + Il test unitario è un processo di sviluppo software in cui le parti testabili più piccole di un'applicazione, denominate unità, vengono esaminate individualmente per verificarne il corretto funzionamento. Chi sviluppa e talvolta il personale del controllo qualità completano i test unitari durante il processo di sviluppo. Per unità solitamente si intende una funzione o una piccola serie di funzioni i cui comportamenti sono strettamente legati. Il punto principale è la presenza di un contesto isolato con un obiettivo. Non dovrebbe avere dipendenze, se presenti queste dovrebbero essere messe sotto mock quando possibile. -Coverage: Solitamente gli unit test permettono di raggiungere alti livelli di code coverage proprio per via della loro granularità. +Coverage: Solitamente gli unit test permettono di raggiungere alti livelli di code coverage proprio per via della loro granularità. Solitamente i problemi nati negli unit test sono più facili da correggere perché riguardano piccole porzioni di codice e molti test sono riutilizzabili anche in altri progetti se si usa codice condiviso. @@ -29,11 +30,13 @@ D'altro canto, se i test sono scritti male o non hanno una buona coverage, danno Il test di integrazione è una tecnica di test del software che si concentra sul test delle interazioni e dell'integrazione tra più componenti o moduli di un sistema software. Ha lo scopo di verificare che i diversi componenti, quando combinati, funzionino correttamente e producano i risultati attesi. Concetti principali: + - **Scope**: Anche qui parliamo di contesto e obiettivi specifici. - **Stubs**: Sostituti di moduli e dipendenze necessari al funzionamento dei test. - **Spettro più ampio**: A differenza dello unit test che verifica un modulo / una funzione / un contesto specifico e ridotto, l’integration testing integra più moduli e ne testa le interdipendenze e la comunicazione. Tipologie di test: + - **Big-bang**: Si creano decine, centinaia, migliaia di test in base alla dimensione della codebase. Si testa tutto, tutto assieme. Solitamente il tutto viene fatto in un singolo integration test, o in pochissimi. Funziona per codebase ridotte. - **Top-down testing**: Approccio incrementale, si parte dai moduli ad altissimo livello (Controller nel caso di un MVC) e si scende al livello più basso (Se si utilizzano i fat model si arriva anche fino a lì). Funziona per codebase grosse, iniziare è più tosta ma ha più impatto, pian piano diventa sempre più facile perché le parti "sopra" sono già state testate. - **Bottom-up testing**: Approccio incrementale al contrario. Si parte da sotto e si va in alto. Anche qui parliamo di grosse codebase, iniziare è più facile ma ha meno impatto, proseguendo anche qui diventa sempre più facile perché l’impalcatura sotto funziona. From e6e0b9649a12dda1eb5abef6d2ab28b0669aa87a Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 7 Oct 2023 17:13:06 +0200 Subject: [PATCH 04/33] chore: aggiunta test coverage + un paio di modifiche provenienti da review --- docs/testing/README.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/docs/testing/README.md b/docs/testing/README.md index bff4898a..30147e26 100644 --- a/docs/testing/README.md +++ b/docs/testing/README.md @@ -90,13 +90,13 @@ Esistono tre tecniche di test, ognuna con un suo scopo ben preciso. Vediamole br - **White-box testing**: Il test _white-box_ è una tecnica di test in cui il tester ha conoscenza dell'implementazione del sistema. - **Grey-box testing**: Il test _grey-box_ è una tecnica di test in cui il tester ha conoscenza parziale dell'implementazione del sistema. -Di solito queste tre tecniche vengono utilizzate per individuare eventuali falle nel sistema. +Di solito queste tre tecniche vengono utilizzate per individuare eventuali falle nel sistema. Solitamente il _Black-box testing_ è la tecnica più utilizzata, in quanto permette di individuare falle che non sono state individuate durante lo sviluppo e non richiede una conoscenza pregressa del sistema. ## Metodologie di testing ### Manual testing -Il manual testing è una metodologia di testing in cui i test vengono eseguiti manualmente dalla figura del tester. Questo approccio ha diversi svantaggi e solitamente viene utilizzato solo per testare le funzionalità più critiche del sistema quando non è possibile automatizzare i test. +Il manual testing è una metodologia di testing in cui i test vengono eseguiti manualmente dalla figura del tester. Questo approccio ha diversi svantaggi e solitamente viene utilizzato solo per testare le funzionalità più critiche del sistema quando non è possibile automatizzare i test. Questa metodologia viene chiamata anche _explorative testing_, tramite la quale si prova a rompere l'applicazione creando scenari difficilmente automatizzabili e scrivendo di conseguenza i test. ### Automated testing @@ -113,3 +113,9 @@ Il test-driven development (TDD) è una metodologia di sviluppo software che pre ### Behavior-driven development Il behavior-driven development (BDD) è una metodologia di sviluppo software che prevede di scrivere i test prima di scrivere il codice, ma con un approccio più orientato al comportamento dell'applicazione. + +## Test Coverage + +La test coverage è una metrica che indica la percentuale di codice sorgente che viene eseguita (_coperta_) durante l'esecuzione dei test. Questa metrica è molto importante, in quanto permette di capire quanto il codice sorgente è stato testato. Solitamente si cerca di raggiungere una test coverage del 100%, ma questo non è sempre possibile. Inoltre, una test coverage del 100% non garantisce che il codice sorgente sia privo di bug, esattamente come una coverage del 50% non garantisce che il codice sorgente sia pieno di bug. Come in moltissimi altri aspetti della programmazione, la parola _dipende_ assume un significato molto importante. + +**La test coverage ci dice quanto del nostro codice si comporta come ci aspettiamo, ma non è detto che ciò che ci aspettiamo sia corretto.** \ No newline at end of file From ef33611780b4be1efe03343d1f28e36775aef293 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 7 Oct 2023 17:13:25 +0200 Subject: [PATCH 05/33] chore: linting --- docs/testing/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/testing/README.md b/docs/testing/README.md index 30147e26..3e3566d3 100644 --- a/docs/testing/README.md +++ b/docs/testing/README.md @@ -118,4 +118,4 @@ Il behavior-driven development (BDD) è una metodologia di sviluppo software che La test coverage è una metrica che indica la percentuale di codice sorgente che viene eseguita (_coperta_) durante l'esecuzione dei test. Questa metrica è molto importante, in quanto permette di capire quanto il codice sorgente è stato testato. Solitamente si cerca di raggiungere una test coverage del 100%, ma questo non è sempre possibile. Inoltre, una test coverage del 100% non garantisce che il codice sorgente sia privo di bug, esattamente come una coverage del 50% non garantisce che il codice sorgente sia pieno di bug. Come in moltissimi altri aspetti della programmazione, la parola _dipende_ assume un significato molto importante. -**La test coverage ci dice quanto del nostro codice si comporta come ci aspettiamo, ma non è detto che ciò che ci aspettiamo sia corretto.** \ No newline at end of file +**La test coverage ci dice quanto del nostro codice si comporta come ci aspettiamo, ma non è detto che ciò che ci aspettiamo sia corretto.** From 62e272d5f6c82d78c4d0ab3d7af38bb5caa23c47 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Tue, 31 Oct 2023 17:59:07 +0100 Subject: [PATCH 06/33] Update docs/testing/README.md --- docs/testing/README.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/docs/testing/README.md b/docs/testing/README.md index 3e3566d3..c56d8aa6 100644 --- a/docs/testing/README.md +++ b/docs/testing/README.md @@ -1,5 +1,3 @@ -# Testing - Il testing è una parte fondamentale di ogni progetto software. In questo capitolo vedremo come testare il nostro codice in modo efficace. ## Piramide del testing From 2149e514d9ffd2c681ddca88ebb2ec7239aa10a3 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Thu, 2 Nov 2023 19:11:28 +0100 Subject: [PATCH 07/33] Update docs/testing/README.md --- docs/testing/README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/testing/README.md b/docs/testing/README.md index c56d8aa6..3e3566d3 100644 --- a/docs/testing/README.md +++ b/docs/testing/README.md @@ -1,3 +1,5 @@ +# Testing + Il testing è una parte fondamentale di ogni progetto software. In questo capitolo vedremo come testare il nostro codice in modo efficace. ## Piramide del testing From 77434f6bd6b0fd3741b092204ad3817f32633633 Mon Sep 17 00:00:00 2001 From: Emilio Junior Francischetti <67055839+frnmjn@users.noreply.github.com> Date: Thu, 9 Nov 2023 08:38:54 +0100 Subject: [PATCH 08/33] PR a Proposta prima bozza capitolo testing (#164) Co-authored-by: Michael Di Prisco --- docs/testing/README.md | 35 +++++++++++++++++++++++++++++++++-- 1 file changed, 33 insertions(+), 2 deletions(-) diff --git a/docs/testing/README.md b/docs/testing/README.md index 3e3566d3..4258eede 100644 --- a/docs/testing/README.md +++ b/docs/testing/README.md @@ -54,7 +54,7 @@ Spesso realizzare questi test è più complesso perché bisogna prima avere idea ### End-to-end test -Il test end-to-end (E2E) è una metodologia di test del software che si concentra sul test dell'intero sistema software dall'inizio alla fine, simulando scenari del mondo reale e interazioni dell'utente. Ha lo scopo di garantire che il sistema funzioni correttamente nel suo insieme e soddisfi i requisiti aziendali desiderati. +Il test end-to-end (E2E) è una metodologia di test del software che si concentra sul test dell'intero sistema software dall'inizio alla fine, simulando scenari del mondo reale e interazioni dell'utente. Ha lo scopo di garantire che il sistema funzioni correttamente nel suo insieme e soddisfi i requisiti aziendali desiderati. A differenza degli altri tipi di test, fin ora trattati, qui il test interagisce con l'applicativo __solo__ attraverso le interfacce più esterne (Browser o Api). E qui sta il punto. I requisiti sono essenzialmente aziendali e non tecnici. @@ -109,10 +109,41 @@ Il continuous testing è una metodologia di testing in cui i test vengono esegui ### Test-driven development Il test-driven development (TDD) è una metodologia di sviluppo software che prevede di scrivere i test prima di scrivere il codice. +La parola Test nell'acronimo è spesso mal interpretata. Il TDD non è uno strumento per testare l'applicazione, ma per far emergere il design dell'applicativo, partendo dai test che vogliamo soddisfare. Questo ci permette di rispettare il principio YAGNI (You aren't gonna need it), ovvero non scrivere codice per esigenze future, ma solo per soddisfare l'implementazione dei test da soddisfare. + +Il TDD inizia con la scrittura dei test prima di scrivere il codice effettivo. Il ciclo TDD - Spesso chiamato _red-green-refactor_ - è semplice ma potente: + +1. Scrivi un Test: Inizia scrivendo un test che descriva il comportamento che desideri implementare. Questo test inizierà sicuramente come un test fallito, poiché il codice non esiste ancora. + +2. Scrivi il Codice Minimale: Scrivi il codice minimo necessario per far passare il test. In questa fase, non preoccuparti troppo della qualità del codice; l'obiettivo è far passare il test. + +3. Rifattorizza il Codice: Ora che il test è passato, puoi iniziare a migliorare la qualità del tuo codice. Rimuovi duplicazioni, migliora la leggibilità e assicurati che il codice sia pulito e ben strutturato. ### Behavior-driven development -Il behavior-driven development (BDD) è una metodologia di sviluppo software che prevede di scrivere i test prima di scrivere il codice, ma con un approccio più orientato al comportamento dell'applicazione. +Il behavior-driven development (BDD) è una metodologia che permette di esplicitare i requisiti funzionali, tramite test. Questo permette una maggior comprensione degli sviluppi, creando un dialogo tra Product Owner e Dev Team, con i test come lingua comune. + +Questo tipo di test viene scritto con un linguaggio chiamato _gherkins_, composto da Feature e vari scenari. Ogni scenario è composto da: + +1. Given: una fase di creazione delle pre-condizioni. +2. When: un'azione sotto test. +3. Then: una condizione da verificare. + +Di seguito un esmpio che descrive una semplice ricerca su Google: + +``` +Feature: Google Searching + As a web surfer, I want to search Google, so that I can learn new things. + + Scenario: Simple Google search + Given a web browser is on the Google page + When the search phrase "panda" is entered + Then results for "panda" are shown +``` + +Un altro vantaggio del TDD è che si sta automaticamente creando una documentazione tecnica. Guardando la descrizione dei test, è facile comprendere come debba comportarsi l'applicazione. + +Non c'è rosa senza spine! Il TDD non è una pratica facile da padroneggiare. Un ottimo modo per iniziare, è l'esercitazione attraverso esercizi mirati, chiamati kata. Piccolo spoiler, qeusti esercizi vengono spesso usati in fase di colloghio. ## Test Coverage From eed19d9070db16b0b154b901da40830257b97d8d Mon Sep 17 00:00:00 2001 From: Emilio Junior Francischetti <67055839+frnmjn@users.noreply.github.com> Date: Sat, 11 Nov 2023 17:31:54 +0100 Subject: [PATCH 09/33] Issue 96 proposta argomento testing ejf (#171) --- docs/testing/README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/testing/README.md b/docs/testing/README.md index 4258eede..6ad63c29 100644 --- a/docs/testing/README.md +++ b/docs/testing/README.md @@ -119,6 +119,10 @@ Il TDD inizia con la scrittura dei test prima di scrivere il codice effettivo. I 3. Rifattorizza il Codice: Ora che il test è passato, puoi iniziare a migliorare la qualità del tuo codice. Rimuovi duplicazioni, migliora la leggibilità e assicurati che il codice sia pulito e ben strutturato. +Un altro vantaggio del TDD è che si sta automaticamente creando una documentazione tecnica. Guardando la descrizione dei test, è facile comprendere come debba comportarsi l'applicazione. + +Non c'è rosa senza spine! Il TDD non è una pratica facile da padroneggiare. Un ottimo modo per iniziare, è l'esercitazione attraverso esercizi mirati, chiamati kata. Piccolo spoiler, qeusti esercizi vengono spesso usati in fase di colloghio. + ### Behavior-driven development Il behavior-driven development (BDD) è una metodologia che permette di esplicitare i requisiti funzionali, tramite test. Questo permette una maggior comprensione degli sviluppi, creando un dialogo tra Product Owner e Dev Team, con i test come lingua comune. @@ -141,10 +145,6 @@ Feature: Google Searching Then results for "panda" are shown ``` -Un altro vantaggio del TDD è che si sta automaticamente creando una documentazione tecnica. Guardando la descrizione dei test, è facile comprendere come debba comportarsi l'applicazione. - -Non c'è rosa senza spine! Il TDD non è una pratica facile da padroneggiare. Un ottimo modo per iniziare, è l'esercitazione attraverso esercizi mirati, chiamati kata. Piccolo spoiler, qeusti esercizi vengono spesso usati in fase di colloghio. - ## Test Coverage La test coverage è una metrica che indica la percentuale di codice sorgente che viene eseguita (_coperta_) durante l'esecuzione dei test. Questa metrica è molto importante, in quanto permette di capire quanto il codice sorgente è stato testato. Solitamente si cerca di raggiungere una test coverage del 100%, ma questo non è sempre possibile. Inoltre, una test coverage del 100% non garantisce che il codice sorgente sia privo di bug, esattamente come una coverage del 50% non garantisce che il codice sorgente sia pieno di bug. Come in moltissimi altri aspetti della programmazione, la parola _dipende_ assume un significato molto importante. From 2414f724cde04ecbb718a1819a6eb23e6c10f7bb Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Thu, 12 Oct 2023 15:59:11 +0200 Subject: [PATCH 10/33] Aggiunta linee guida in CONTRIBUTING.md (#148) --- CONTRIBUTING.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index d6e6e6ed..3b79e7a6 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -42,3 +42,7 @@ git commit -m "feat: Aggiunta nuova pagina" Il libro è, in questo momento, orientato ad un pubblico italiano. Volendo essere accessibile alla platea più ampia possibile, è necessario utilizzare un linguaggio semplice e chiaro, espresso in lingua italiana, per i contenuti, le cartelle, i commit, le Pull Requests, i commenti, ecc. Seppur abituati a scrivere in inglese commit e Pull Requests, richiediamo a chi contribuisce di utilizzare la lingua italiana anche in questi casi, _al netto del `` dei commit_ per seguire i [Conventional Commits](#conventional-commits), che resteranno in inglese. + +## Linee Guida + +Prima di stendere contenuti o proporre delle Pull Request si suggerisce di dare una lettura alle [Linee Guida](https://github.com/Il-Libro-Open-Source/book/blob/main/GUIDELINES.md) (E relativo [Cheatsheet](https://github.com/Il-Libro-Open-Source/book/blob/main/GUIDELINES-CHEATSHEET.md)) da rispettare quando si interagisce con il repository. From e67847a32cc9ae6a7d217154d22b06747b5c9e4b Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Thu, 26 Oct 2023 11:34:54 +0200 Subject: [PATCH 11/33] Creazione FUNDING.yml (#154) --- .github/FUNDING.yml | 1 + 1 file changed, 1 insertion(+) create mode 100644 .github/FUNDING.yml diff --git a/.github/FUNDING.yml b/.github/FUNDING.yml new file mode 100644 index 00000000..08819105 --- /dev/null +++ b/.github/FUNDING.yml @@ -0,0 +1 @@ +open_collective: il-libro-open-source From 2945a55a8131e9c9067fdd1c4fa889abfe1ec851 Mon Sep 17 00:00:00 2001 From: Nicola Erario Date: Tue, 31 Oct 2023 09:12:57 +0100 Subject: [PATCH 12/33] Aggiunge il capitolo Introduzione all'indice del libro (#149) --- CONTRIBUTING.md | 9 +++++++-- docs/en/.gitkeep | 0 docs/index.md | 3 +-- docs/{introduzione/README.md => it/introduzione.md} | 0 lefthook.yml | 2 +- package.json | 5 +++-- 6 files changed, 12 insertions(+), 7 deletions(-) create mode 100644 docs/en/.gitkeep rename docs/{introduzione/README.md => it/introduzione.md} (100%) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 3b79e7a6..593fc24b 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -17,7 +17,7 @@ Tutti i file markdown devono essere formattati con [Prettier](https://prettier.i Per formattare da linea di comando tutti i file è necessario avere [Node](https://nodejs.org/it) installato sul proprio computer e lanciare il seguente comando nella cartella del repository: ```bash -npm run format:write -- *.md +npm run format:write ``` Fortunatamente i principali IDE supportano Prettier tramite delle estensioni, di seguito alcuni esempi: @@ -34,7 +34,7 @@ Per mantenere uno storico e poter costruire dei changelog è richiesto a tutti i In pratica è necessario utilizzare dei prefissi per i commit che indicano il tipo di commit e il contesto, ad esempio: ```bash -git commit -m "feat: Aggiunta nuova pagina" +git commit -m "feat: aggiunta nuova pagina" ``` ## Lingua e contenuti @@ -43,6 +43,11 @@ Il libro è, in questo momento, orientato ad un pubblico italiano. Volendo essere accessibile alla platea più ampia possibile, è necessario utilizzare un linguaggio semplice e chiaro, espresso in lingua italiana, per i contenuti, le cartelle, i commit, le Pull Requests, i commenti, ecc. Seppur abituati a scrivere in inglese commit e Pull Requests, richiediamo a chi contribuisce di utilizzare la lingua italiana anche in questi casi, _al netto del `` dei commit_ per seguire i [Conventional Commits](#conventional-commits), che resteranno in inglese. +Per quanto riguarda i capitoli del libro, è stata già predisposta una futura integrazione di ulteriori lingue (traduzioni) utilizzando un approccio `language driven` per la struttura delle cartelle. Si avrà quindi, ad esempio: `docs/it/nome-del-capitolo.md` per la lingua italiana, `docs/en/name-of-the-chapter.md` per l'inglese, e così via. + +> [!NOTE] +> Il nome del file (`nome-del-capitolo.md`) rappresenta, a tutti gli effetti, lo `slug` dell' url. Cercando sempre di mantenere una nomenclatura efficace e concisa (esempio: ✅ `sviluppo-mobile` e non ❌ `capitolo-sulle-metodologie-di-sviluppo-per-applicazioni-mobile`), è necessario utilizzare la convenzione di nomenclatura `Kebab case` (quindi parole in minuscolo separate da un `-`). + ## Linee Guida Prima di stendere contenuti o proporre delle Pull Request si suggerisce di dare una lettura alle [Linee Guida](https://github.com/Il-Libro-Open-Source/book/blob/main/GUIDELINES.md) (E relativo [Cheatsheet](https://github.com/Il-Libro-Open-Source/book/blob/main/GUIDELINES-CHEATSHEET.md)) da rispettare quando si interagisce con il repository. diff --git a/docs/en/.gitkeep b/docs/en/.gitkeep new file mode 100644 index 00000000..e69de29b diff --git a/docs/index.md b/docs/index.md index c75af1c9..84cab0c0 100644 --- a/docs/index.md +++ b/docs/index.md @@ -1,4 +1,3 @@ ## Indice del libro -- [Capitolo di esempio](index.md) - - [Paragrafo di esempio](index.md) +- [Introduzione](./it/introduzione.md) diff --git a/docs/introduzione/README.md b/docs/it/introduzione.md similarity index 100% rename from docs/introduzione/README.md rename to docs/it/introduzione.md diff --git a/lefthook.yml b/lefthook.yml index b7f814da..7afb9487 100644 --- a/lefthook.yml +++ b/lefthook.yml @@ -3,7 +3,7 @@ pre-commit: commands: prettier: glob: "*.md" - run: npm run format:write {staged_files} + run: npm run format:write:automation {staged_files} commit-msg: scripts: "commitlint.sh": diff --git a/package.json b/package.json index d95b47ca..15441910 100644 --- a/package.json +++ b/package.json @@ -1,7 +1,8 @@ { "scripts": { - "format:check": "npx prettier --check \"**/*.md\"", - "format:write": "prettier --write" + "format:check": "npx prettier --check '**/*.md'", + "format:write": "prettier --write '**/*.md'", + "format:write:automation": "prettier --write" }, "devDependencies": { "@commitlint/cli": "^17.7.1", From 0c4d2d7f8564901ccff37dcb37dc13e8520d6a34 Mon Sep 17 00:00:00 2001 From: Nicola Erario Date: Tue, 31 Oct 2023 17:57:10 +0100 Subject: [PATCH 13/33] Rimuove il titolo del libro da Introduzione (#161) --- docs/it/introduzione.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/docs/it/introduzione.md b/docs/it/introduzione.md index dbe81346..9b6dbfb7 100644 --- a/docs/it/introduzione.md +++ b/docs/it/introduzione.md @@ -1,5 +1,3 @@ -# Il Libro Open Source - ## Benvenuto Chiunque tu sia, da qualunque posto tu provenga, benvenuto in un viaggio incredibile nel mondo dello sviluppo software. From d2ad3ae62e8eca9e95a3c8e65befa71859cde62b Mon Sep 17 00:00:00 2001 From: Simone Gizzi Date: Thu, 2 Nov 2023 11:31:14 +0100 Subject: [PATCH 14/33] Aggiunge capitolo Cosa significa essere dev (#111) Co-authored-by: Michael Di Prisco Co-authored-by: Corrado Petrelli Co-authored-by: Angelo Cassano --- docs/it/cosa-significa-essere-dev.md | 95 ++++++++++++++++++++++++++++ 1 file changed, 95 insertions(+) create mode 100644 docs/it/cosa-significa-essere-dev.md diff --git a/docs/it/cosa-significa-essere-dev.md b/docs/it/cosa-significa-essere-dev.md new file mode 100644 index 00000000..4221391f --- /dev/null +++ b/docs/it/cosa-significa-essere-dev.md @@ -0,0 +1,95 @@ +_Cosa significa "essere dev"?_ + +La domanda, di per sé, è piuttosto semplice. + +Non si può dire però altrettanto per la risposta... o, per meglio dire, le risposte. + +Ebbene sì, essere dev va oltre una singola e banale definizione: a tale domanda si potrebbe rispondere "_Essere dev significa svolgere una professione dedita alla stesura del codice e con il fine ultimo di creare prodotti digitali_"... ma sarebbe riduttivo. + +Oppure si potrebbe dire che "_Essere dev significa essere persone altamente competenti nel campo informatico; figure prettamente tecniche e verticalizzate in uno o più linguaggi di programmazione_"...ma anche qui, **sarebbe come indossare un maglione troppo stretto**: dopo un po' pizzica. + +Potremmo continuare dicendo che "_Essere dev significa essere artigiani del mondo digital: un professionista in grado di trovare la soluzione ad uno specifico problema ed essere in grado di applicarla in un contesto digitale_". + +O ancora, volendola vedere sotto un punto di vista più etico: "_Essere dev significa abbracciare il movimento Open Source, apportando il proprio contributo senza pretendere nulla in cambio e contribuendo così a far crescere la community stessa, oltre che il proprio know-how_". + +La verità, caro lettore, è che essere dev significa essere tante cose contemporaneamente. + +Tante _definizioni_, se così vogliamo chiamarle, che però affondano le loro radici su dei principi solidi e genuini: [**passione**](#la-passione-il-combustibile-per-eccellenza), [**curiosità**](#la-curiosità-il-potere-della-scoperta), [**empatia**](#lempatia-la-capacità-di-impersonare-il-prossimo) e [**contaminazione**](#la-contaminazione-fare-squadra-nel-modo-giusto); principi su cui, peraltro, nasce questo libro. + +Caratteristiche che nulla hanno a che fare con la scrittura del codice, né presentano alcun tipo di legame diretto con specifiche competenze tecniche; nonostante ciò, risultano essere caratteristiche **fondamentali** per intraprendere questa carriera al meglio, lasciarsi coinvolgere da essa e riuscire a portare valore in questo settore. + +## La passione: il combustibile per eccellenza + +Decidere di "diventare dev" significa scegliere di "sacrificare" parte del proprio tempo al fine di raggiungere un obiettivo; non sarà un percorso facile, tantomeno breve; ci saranno momenti di eccitazione, ma anche di sconforto; ci saranno giorni in cui tutto sembrerà andare per il verso giusto, ed altri in cui ogni nostra singola attività verrà minata dalle difficoltà che ci si pareranno davanti; ci saranno concetti che domeremo con estrema facilità, ed altri in cui ne usciremo sconfitti e con la coda tra le gambe. + +Fa tutto parte del gioco: _abbraccialo, comprendilo, e fallo tuo_; magari non oggi e forse nemmeno domani, ma arriverà il momento in cui riuscirai dove prima hai fallito. + +Solitamente, quando ci appassioniamo a qualcosa tendiamo a dedicare molto del nostro tempo a quella specifica attività; la coltiviamo negli anni prendendocene cura, approfondendo ogni aspetto e cercando di scoprire ogni singola caratteristica che possiede...in buona sostanza: _la rendiamo nostra_. + +Forti di questa consapevolezza possiamo quindi affermare che ciò che farà la differenza tra il nostro successo e la nostra sconfitta sarà la passione che metteremo in ciò che facciamo; se non avremo passione, difficilmente riusciremo ad accettare una sconfitta e a rialzarci più forti di prima; senza passione non riusciremo a trovare la forza di studiare, magari dopo una giornata di lavoro. + +Se però avremo passione, avremo dalla nostra una risorsa sorprendente: il dono della _Perseveranza_. + +Non importerà quindi quante volte proveremo, senza successo, a completare un esercizio o ad imparare una tecnologia: avremo sempre la forza necessaria per incassare il colpo, prendere fiato, e provare a superare noi stessi. + +Il mio consiglio per te che leggi, è quello di tenere a mente, per l'intera durata di questo manoscritto, il ruolo che ricopre la passione riguardo al percorso che hai scelto di intraprendere: se avrai passione, avrai la forza di perseverare. + +_Persevera con passione: a quel punto l'unico limite che avrai, sarai tu._ + +## La curiosità: il potere della scoperta + +Qualità caratteristica dell'essere umano, la curiosità è l'impulso a scoprire, ricercare e comprendere ciò che ancora non conosciamo. Se cerchiamo la definizione di "curiosità" su Wikipedia infatti, scopriamo che: + +> _La curiosità è un aspetto emozionale che descrive un numero di meccanismi e comportamenti che hanno come fine il placare l'impulso degli esseri viventi a trarre informazioni ed interagire con l'ambiente._ + +Il percorso che hai deciso di intraprendere pullula di informazioni che non aspettano altro che essere scoperte, studiate e messe in pratica; ci teniamo però a prepararti: alcune nozioni potranno risultarti piuttosto semplici, altre dannatamente complesse. + +Nonostante ciò, non scoraggiarti; la nostra intenzione non è quella di spaventarti, ma di consigliarti e guidarti nel migliore dei modi; proprio per questo, ti inviatiamo a riflettere su un aspetto tanto scontato quanto potente: il potere dell'informazione libera. + +Proprio come questo libro, in rete esistono miliardi di informazioni a cui puoi avere accesso: aspettano solo di essere ricercate! Queste pagine che stai leggendo sono presenti sul web, e molto probabilmente ne sei a conoscenza perché è stato semplice imbattersi in esse navigando per la rete, o magari perché chi ti ha consigliato questo libro lo ha cercato a sua volta. Poco importa, quello che è davvero importante è che tu prenda consapevolezza del fatto che il web pullula di informazioni a cui puoi accedere, e che l'unica cosa che ti separa da esse, indovina un po', _sei tu_! + +Le informazioni presenti in rete però, per quanto siano molteplici e liberamente fruibili, da sole non hanno alcun effetto sulla tua formazione; analogamente a quanto avviene con un esplosivo, la polvere da sparo, per quanto potente possa essere, da sola non basta; serve un innesco o, per meglio dire, serve **una scintilla che sia in grado di innescare la miccia**. + +A questo punto, a te che leggi, avrai capito dove vogliamo andare a parare: ciò che non deve mai mancare in te è la curiosità! + +Essa sarà la scintilla in grado di innescare in te una forma mentis vincente, prona all'apprendimento e alla crescita professionale; fintanto che questa scintilla continuerà a scattare, non avrai limiti nell'apprendimento: anche qui, l'unico limite che avrai, _sarai tu_. + +## L'empatia: la capacità di impersonare il prossimo + +Forse ti starai chiedendo cosa c'entri una qualità come l'empatia in un percorso di apprendimento e crescita professionale in un settore come quello della programmazione. + +Se ad un primo impatto potrebbe sembrare un dubbio legittimo, la verità è che l'empatia in questo caso gioca un ruolo fondamentale. + +Durante il tuo percorso, presto o tardi ti capiterà di imbatterti in un problema a cui non saprai far fronte; a quel punto, molto probabilmente il tuo primo impulso sarà quello di cercare in rete una soluzione e, pensa un po', la troverai! + +Penserai "_Che fortuna che ho avuto!_", ed è qui che potresti sbagliarti...**sbaglieresti di grosso**. + +Quella soluzione, che molto probabilmente ti aiuterà a risolvere il tuo problema, è lì per un motivo ben preciso: qualcuno, prima di te, ha avuto il tuo stesso problema; al contrario di te però, quel qualcuno non è stato "_così fortunato_" da trovare una soluzione online, ma è stato abbastanza empatico da mettersi nei panni di chi, come te, quel problema prima o poi lo avrebbe avuto; una volta trovata la soluzione quindi, si è adoperato per metterla a disposizione di tutti, **gratuitamente** e in maniera del tutto spontanea. + +Questo, a te che leggi, è uno dei principi fondamentali su cui verte questo libro: **la condivisione libera del sapere (in questo caso collettivo) con chiunque ne abbia bisogno**. + +Ed è proprio per questo che ti parlo di empatia: durante il tuo percorso, che sia grazie a questo libro o ad altro, apprenderai un'enorme quantità di informazioni; mentre lo farai, rifletti sul perché ti è possibile farlo, e domandati se le nozioni da te apprese potranno in futuro essere utili a chi muoverà i primi passi in questo settore, proprio come stai facendo tu ora grazie al manoscritto che stai leggendo. + +Forte di questa consapevolezza, prendi coraggio e sii empatico: pubblica, ovunque tu voglia e in qualsiasi formato tu preferisca, ciò che hai imparato: per te sarà un notevole esercizio di ripasso e pratica sul campo; chiunque fruirà dei tuoi contenuti te ne sarà grato e sarà propenso a diventare un membro della tua community, ma sopra ogni cosa sarà ispirato a condividere a sua volta le nozioni che imparerà lungo il suo percorso...proprio come hai fatto tu prima di lui. + +Ciò che vogliamo trasmetterti è la propensione ad adottare uno spirito di condivisione: oltre ad essere il cuore pulsante del movimento Open Source, e quindi del libro che stai leggendo, è anche un principio nobile e al contempo stesso utile; qualora non ne comprenderai subito il senso ed il potenziale, o magari ti sembrerà una perdita di tempo, tieni a mente quanto segue: arriverà il giorno in cui ringrazierai chi, prima di te, ha seguito il nostro consiglio. + +Fidati di chi, prima di te, è stato aiutato e che oggi è qui a condividere il suo sapere. + +## La contaminazione: fare squadra nel modo giusto + +"Indossare i panni di dev", tra le tante altre cose, significa _essere parte di una comunità_. + +Una comunità composta da altri professionisti, persone che come te hanno scelto di lavorare in questo settore. + +Con il tempo, magari collaborando ad un progetto Open Source o lavorando in qualche azienda, ti troverai a dover collaborare a stretto contatto (che sia esso virtuale o fisico) con altri sviluppatori. + +Scenario ben diverso da ciò che magari sei stato abituato a fare fino a quel momento; d'altro canto, un conto è scrivere codice in solitudine per un progetto a cui stiamo lavorando, e un conto è scrivere codice collaborativo con un numero indefinito di altre persone, tutte con lo stesso obiettivo. + +In queste circostanze, ciò che solitamente fa la differenza è lo spirito con cui si affrontano queste situazioni; partire prevenuti non serve a niente, e anzi il più delle volte potrebbe addirittura risultare controproducente; ha molto più senso invece partire dall'assunto che **ognuno di noi può insegnarci qualcosa**, e dunque, **possiamo sempre imparare qualcosa, anche da chi è meno esperto di noi**. + +Adottare un atteggiamento del genere significa abbracciare l'idea di poter apprendere sempre qualcosa, indipendentemente dal nostro grado di conoscenza o da chi abbiamo davanti...significa **lasciarsi contaminare**. + +La contaminazione, in un gruppo di persone aventi lo stesso obiettivo, è un'atteggiamento prono al successo, è inclusivo e privo di qualsiasi pregiudizio di genere: è un modo sano di fare gruppo, contribuendo alla sua crescita e apprendendo da esso. + +In fondo, come abbiamo già detto qualche riga fa, Open Source significa anche questo: contribuire condividendo il proprio sapere, ed apprendere da chi a sua volta condivide il suo sapere con noi. From cc1b988360e37428e1d12339a2f2bff1fdc1e085 Mon Sep 17 00:00:00 2001 From: Simone Gizzi Date: Thu, 2 Nov 2023 18:26:41 +0100 Subject: [PATCH 15/33] Aggiunge all'indice il capitolo Cosa significa essere dev (#163) --- docs/index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/index.md b/docs/index.md index 84cab0c0..3a6544d2 100644 --- a/docs/index.md +++ b/docs/index.md @@ -1,3 +1,4 @@ ## Indice del libro - [Introduzione](./it/introduzione.md) +- [Cosa significa essere Dev](./it/cosa-significa-essere-dev.md) From 24b3cb25b44f0ece932f4362cc89571ee7d8b7b0 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Fri, 3 Nov 2023 17:57:05 +0100 Subject: [PATCH 16/33] Aggiunta del titolo al capitolo "cosa significa essere dev" (#165) --- docs/it/cosa-significa-essere-dev.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/cosa-significa-essere-dev.md b/docs/it/cosa-significa-essere-dev.md index 4221391f..e245f64d 100644 --- a/docs/it/cosa-significa-essere-dev.md +++ b/docs/it/cosa-significa-essere-dev.md @@ -1,4 +1,4 @@ -_Cosa significa "essere dev"?_ +# _Cosa significa "essere dev"?_ La domanda, di per sé, è piuttosto semplice. From 5fc4e66af5bf92edc937da4f270faea6e3333ff8 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 4 Nov 2023 16:58:05 +0100 Subject: [PATCH 17/33] Adattamento nomine Ambassador (#166) --- AMBASSADORS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/AMBASSADORS.md b/AMBASSADORS.md index 72bd495d..6c5ac286 100644 --- a/AMBASSADORS.md +++ b/AMBASSADORS.md @@ -11,5 +11,5 @@ # Come si diventa Ambassador? 1. È presente una [discussione ad hoc](https://github.com/Il-Libro-Open-Source/book/discussions/5) che resterà sempre aperta permettendo a chiunque di candidarsi per un posto tra gli Ambassadors. -2. Ogni _X_ settimane, numero che stabiliremo assieme in seguito, i candidati di quel periodo e quelli precedentemente non eletti verranno votati in apposite survey per riempire i posti aperti in quello specifico momento. I candidati verranno nominati Ambassador a partire dal candidato con il maggior numero di punti fino ad esaurimento posti disponibili alla fine degli _Y_ giorni stabiliti assieme per considerare chiuso il processo di nomina. +2. A periodi non ancora definiti, i candidati verranno votati in apposite survey per riempire i posti aperti in quello specifico momento. I candidati verranno nominati Ambassador a partire dal candidato con il maggior numero di punti fino ad esaurimento posti disponibili alla fine dei giorni stabiliti assieme per considerare chiuso il processo di nomina. 3. Una volta nominato, un ambassador diventerà effettivo nel tempo pratico necessario agli owner del progetto di nominarlo, quindi da una manciata di ore a qualche giorno in base alla disponibilità. From 76f3961927e5e52bab2d86d8171dc6f3aff3e297 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 4 Nov 2023 16:59:00 +0100 Subject: [PATCH 18/33] Aggiunta approvazione contenuti ambassador (#167) --- GUIDELINES-CONTENUTI.md | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 GUIDELINES-CONTENUTI.md diff --git a/GUIDELINES-CONTENUTI.md b/GUIDELINES-CONTENUTI.md new file mode 100644 index 00000000..50874702 --- /dev/null +++ b/GUIDELINES-CONTENUTI.md @@ -0,0 +1,37 @@ +# Linee guida per l'approvazione e la disapprovazione dei contenuti + +Attualmente sono presenti quattro modalità di contribuzione: + +- Un membro del team Ambassador può aprire una PR da un _branch_ verso il branch _main_. +- Un contributor esterno - o Ambassador - può aprire una PR da un proprio _fork_ verso il branch _main_. +- Un contributor esterno - o Ambassador - può aprire una PR da un proprio _fork_ verso un _branch_ di un Ambassador. + +Queste quattro modalità seguiranno dei processi di approvazione contenuti che verranno descritti in questo documento. + +## Approvazione di un contenuto verso un branch + +Per l'approvazione di un contenuto all'interno di un branch, che sia da parte di un Ambassador che di una figura esterna, sarà sufficiente: + +- Approvazione di almeno il 50%+1 degli Ambassador assegnatari. In caso di non raggiungimento del quorum entro 15 giorni dall'apertura della PR, un qualsiasi altro Ambassador potrà fare le veci degli assegnatari non votanti. +- Superato il tempo massimo di 15 giorni dall'apertura della PR - O 15 giorni dall'ultimo commento o approvazione da parte di un Ambassador -, qualora non venga raggiunto il quorum questa sarà considerata non valida e verrà chiusa da qualsiasi Ambassador avesse modo di farlo e verrà richiesto alla persona che ha aperto la PR di riproporla cercando di creare più coinvolgimento o di modificarne il wording. + +Non si ritiene necessaria la presenza del Drafting Group in questa fase in quanto sarà comunque necessario un successivo passaggio prima dell'inserimento in _main_ dei contenuti nel quale loro saranno coinvolti e questo step creerebbe solo eccessivo lavoro per il gruppo. + +Si precisa che il conteggio dei tempi di approvazione e raggiungimento del quorum inizia quando la Pull Request (PR) è contrassegnata come _ready for review_, e non più in _draft_. + +## Approvazione di un contenuto verso _main_ + +Per l'approvazione di un contenuto all'interno di main, che sia da parte di un Ambassador che di una figura esterna, sarà sufficiente: + +- Approvazione di almeno 5 Ambassador. +- Approvazione di almeno 1 membro del Drafting Group. +- Superato il tempo massimo di 15 giorni dall'apertura della PR - O 15 giorni dall'ultimo commento o approvazione da parte di un Ambassador -, questa sarà considerata non valida e verrà chiusa da qualsiasi Ambassador avesse modo di farlo e verrà richiesto alla persona che ha aperto la PR di riproporla cercando di creare più coinvolgimento o di modificarne il wording. + +## Disapprovazione di un contenuto + +Per esprimere la disapprovazione dei contenuti sarà sufficiente che un membro del team Ambassador commenti la PR indicando in maniera chiara il proprio dissenso (Pollice giù 👎, commento chiaro es. "Non approvo questo contenuto"), al quale deve seguire una spiegazione chiara. Il semplice dissenso non motivato non verrà considerato come valido. + +La disapprovazione andrà a ridurre di 1 i numeri per il raggiungimento dei criteri di cui sopra. + +Di conseguenza, a titolo di esempio, una PR verso main con 5 voti a favore e approvazione del drafting group ma con una disapprovazione renderà necessaria un'ulteriore approvazione per poter passare. +Lo stesso vale per il conteggio del Drafting Group, per cui la disapprovazione da parte di uno dei suoi membri richiederà l'approvazione di altri 2 di essi per raggiungere il netto positivo di 1. From 62c3df0c6a3fb0a55fa8fc6ebdd5891ddedc9e8d Mon Sep 17 00:00:00 2001 From: Simone Gizzi Date: Sat, 4 Nov 2023 16:59:26 +0100 Subject: [PATCH 19/33] Aggiunta licenza del progetto (#160) Co-authored-by: Michael Di Prisco --- LICENSE.md | 429 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 429 insertions(+) create mode 100644 LICENSE.md diff --git a/LICENSE.md b/LICENSE.md new file mode 100644 index 00000000..11976172 --- /dev/null +++ b/LICENSE.md @@ -0,0 +1,429 @@ +Attribution-NonCommercial-ShareAlike 4.0 International + +======================================================================= + +Creative Commons Corporation ("Creative Commons") is not a law firm and +does not provide legal services or legal advice. Distribution of +Creative Commons public licenses does not create a lawyer-client or +other relationship. Creative Commons makes its licenses and related +information available on an "as-is" basis. Creative Commons gives no +warranties regarding its licenses, any material licensed under their +terms and conditions, or any related information. Creative Commons +disclaims all liability for damages resulting from their use to the +fullest extent possible. + +Using Creative Commons Public Licenses + +Creative Commons public licenses provide a standard set of terms and +conditions that creators and other rights holders may use to share +original works of authorship and other material subject to copyright +and certain other rights specified in the public license below. The +following considerations are for informational purposes only, are not +exhaustive, and do not form part of our licenses. + + Considerations for licensors: Our public licenses are + intended for use by those authorized to give the public + permission to use material in ways otherwise restricted by + copyright and certain other rights. Our licenses are + irrevocable. Licensors should read and understand the terms + and conditions of the license they choose before applying it. + Licensors should also secure all rights necessary before + applying our licenses so that the public can reuse the + material as expected. Licensors should clearly mark any + material not subject to the license. This includes other CC- + licensed material, or material used under an exception or + limitation to copyright. More considerations for licensors: + wiki.creativecommons.org/Considerations_for_licensors + + Considerations for the public: By using one of our public + licenses, a licensor grants the public permission to use the + licensed material under specified terms and conditions. If + the licensor's permission is not necessary for any reason--for + example, because of any applicable exception or limitation to + copyright--then that use is not regulated by the license. Our + licenses grant only permissions under copyright and certain + other rights that a licensor has authority to grant. Use of + the licensed material may still be restricted for other + reasons, including because others have copyright or other + rights in the material. A licensor may make special requests, + such as asking that all changes be marked or described. + Although not required by our licenses, you are encouraged to + respect those requests where reasonable. More considerations + for the public: + wiki.creativecommons.org/Considerations_for_licensees + +======================================================================= + +Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International +Public License + +By exercising the Licensed Rights (defined below), You accept and agree +to be bound by the terms and conditions of this Creative Commons +Attribution-NonCommercial-ShareAlike 4.0 International Public License +("Public License"). To the extent this Public License may be +interpreted as a contract, You are granted the Licensed Rights in +consideration of Your acceptance of these terms and conditions, and the +Licensor grants You such rights in consideration of benefits the +Licensor receives from making the Licensed Material available under +these terms and conditions. + +Section 1 -- Definitions. + +a. Adapted Material means material subject to Copyright and Similar +Rights that is derived from or based upon the Licensed Material +and in which the Licensed Material is translated, altered, +arranged, transformed, or otherwise modified in a manner requiring +permission under the Copyright and Similar Rights held by the +Licensor. For purposes of this Public License, where the Licensed +Material is a musical work, performance, or sound recording, +Adapted Material is always produced where the Licensed Material is +synched in timed relation with a moving image. + +b. Adapter's License means the license You apply to Your Copyright +and Similar Rights in Your contributions to Adapted Material in +accordance with the terms and conditions of this Public License. + +c. BY-NC-SA Compatible License means a license listed at +creativecommons.org/compatiblelicenses, approved by Creative +Commons as essentially the equivalent of this Public License. + +d. Copyright and Similar Rights means copyright and/or similar rights +closely related to copyright including, without limitation, +performance, broadcast, sound recording, and Sui Generis Database +Rights, without regard to how the rights are labeled or +categorized. For purposes of this Public License, the rights +specified in Section 2(b)(1)-(2) are not Copyright and Similar +Rights. + +e. Effective Technological Measures means those measures that, in the +absence of proper authority, may not be circumvented under laws +fulfilling obligations under Article 11 of the WIPO Copyright +Treaty adopted on December 20, 1996, and/or similar international +agreements. + +f. Exceptions and Limitations means fair use, fair dealing, and/or +any other exception or limitation to Copyright and Similar Rights +that applies to Your use of the Licensed Material. + +g. License Elements means the license attributes listed in the name +of a Creative Commons Public License. The License Elements of this +Public License are Attribution, NonCommercial, and ShareAlike. + +h. Licensed Material means the artistic or literary work, database, +or other material to which the Licensor applied this Public +License. + +i. Licensed Rights means the rights granted to You subject to the +terms and conditions of this Public License, which are limited to +all Copyright and Similar Rights that apply to Your use of the +Licensed Material and that the Licensor has authority to license. + +j. Licensor means the individual(s) or entity(ies) granting rights +under this Public License. + +k. NonCommercial means not primarily intended for or directed towards +commercial advantage or monetary compensation. For purposes of +this Public License, the exchange of the Licensed Material for +other material subject to Copyright and Similar Rights by digital +file-sharing or similar means is NonCommercial provided there is +no payment of monetary compensation in connection with the +exchange. + +l. Share means to provide material to the public by any means or +process that requires permission under the Licensed Rights, such +as reproduction, public display, public performance, distribution, +dissemination, communication, or importation, and to make material +available to the public including in ways that members of the +public may access the material from a place and at a time +individually chosen by them. + +m. Sui Generis Database Rights means rights other than copyright +resulting from Directive 96/9/EC of the European Parliament and of +the Council of 11 March 1996 on the legal protection of databases, +as amended and/or succeeded, as well as other essentially +equivalent rights anywhere in the world. + +n. You means the individual or entity exercising the Licensed Rights +under this Public License. Your has a corresponding meaning. + +Section 2 -- Scope. + +a. License grant. + + 1. Subject to the terms and conditions of this Public License, + the Licensor hereby grants You a worldwide, royalty-free, + non-sublicensable, non-exclusive, irrevocable license to + exercise the Licensed Rights in the Licensed Material to: + + a. reproduce and Share the Licensed Material, in whole or + in part, for NonCommercial purposes only; and + + b. produce, reproduce, and Share Adapted Material for + NonCommercial purposes only. + + 2. Exceptions and Limitations. For the avoidance of doubt, where + Exceptions and Limitations apply to Your use, this Public + License does not apply, and You do not need to comply with + its terms and conditions. + + 3. Term. The term of this Public License is specified in Section + 6(a). + + 4. Media and formats; technical modifications allowed. The + Licensor authorizes You to exercise the Licensed Rights in + all media and formats whether now known or hereafter created, + and to make technical modifications necessary to do so. The + Licensor waives and/or agrees not to assert any right or + authority to forbid You from making technical modifications + necessary to exercise the Licensed Rights, including + technical modifications necessary to circumvent Effective + Technological Measures. For purposes of this Public License, + simply making modifications authorized by this Section 2(a) + (4) never produces Adapted Material. + + 5. Downstream recipients. + + a. Offer from the Licensor -- Licensed Material. Every + recipient of the Licensed Material automatically + receives an offer from the Licensor to exercise the + Licensed Rights under the terms and conditions of this + Public License. + + b. Additional offer from the Licensor -- Adapted Material. + Every recipient of Adapted Material from You + automatically receives an offer from the Licensor to + exercise the Licensed Rights in the Adapted Material + under the conditions of the Adapter's License You apply. + + c. No downstream restrictions. You may not offer or impose + any additional or different terms or conditions on, or + apply any Effective Technological Measures to, the + Licensed Material if doing so restricts exercise of the + Licensed Rights by any recipient of the Licensed + Material. + + 6. No endorsement. Nothing in this Public License constitutes or + may be construed as permission to assert or imply that You + are, or that Your use of the Licensed Material is, connected + with, or sponsored, endorsed, or granted official status by, + the Licensor or others designated to receive attribution as + provided in Section 3(a)(1)(A)(i). + +b. Other rights. + + 1. Moral rights, such as the right of integrity, are not + licensed under this Public License, nor are publicity, + privacy, and/or other similar personality rights; however, to + the extent possible, the Licensor waives and/or agrees not to + assert any such rights held by the Licensor to the limited + extent necessary to allow You to exercise the Licensed + Rights, but not otherwise. + + 2. Patent and trademark rights are not licensed under this + Public License. + + 3. To the extent possible, the Licensor waives any right to + collect royalties from You for the exercise of the Licensed + Rights, whether directly or through a collecting society + under any voluntary or waivable statutory or compulsory + licensing scheme. In all other cases the Licensor expressly + reserves any right to collect such royalties, including when + the Licensed Material is used other than for NonCommercial + purposes. + +Section 3 -- License Conditions. + +Your exercise of the Licensed Rights is expressly made subject to the +following conditions. + +a. Attribution. + + 1. If You Share the Licensed Material (including in modified + form), You must: + + a. retain the following if it is supplied by the Licensor + with the Licensed Material: + + i. identification of the creator(s) of the Licensed + Material and any others designated to receive + attribution, in any reasonable manner requested by + the Licensor (including by pseudonym if + designated); + + ii. a copyright notice; + + iii. a notice that refers to this Public License; + + iv. a notice that refers to the disclaimer of + warranties; + + v. a URI or hyperlink to the Licensed Material to the + extent reasonably practicable; + + b. indicate if You modified the Licensed Material and + retain an indication of any previous modifications; and + + c. indicate the Licensed Material is licensed under this + Public License, and include the text of, or the URI or + hyperlink to, this Public License. + + 2. You may satisfy the conditions in Section 3(a)(1) in any + reasonable manner based on the medium, means, and context in + which You Share the Licensed Material. For example, it may be + reasonable to satisfy the conditions by providing a URI or + hyperlink to a resource that includes the required + information. + 3. If requested by the Licensor, You must remove any of the + information required by Section 3(a)(1)(A) to the extent + reasonably practicable. + +b. ShareAlike. + + In addition to the conditions in Section 3(a), if You Share + Adapted Material You produce, the following conditions also apply. + + 1. The Adapter's License You apply must be a Creative Commons + license with the same License Elements, this version or + later, or a BY-NC-SA Compatible License. + + 2. You must include the text of, or the URI or hyperlink to, the + Adapter's License You apply. You may satisfy this condition + in any reasonable manner based on the medium, means, and + context in which You Share Adapted Material. + + 3. You may not offer or impose any additional or different terms + or conditions on, or apply any Effective Technological + Measures to, Adapted Material that restrict exercise of the + rights granted under the Adapter's License You apply. + +Section 4 -- Sui Generis Database Rights. + +Where the Licensed Rights include Sui Generis Database Rights that +apply to Your use of the Licensed Material: + +a. for the avoidance of doubt, Section 2(a)(1) grants You the right +to extract, reuse, reproduce, and Share all or a substantial +portion of the contents of the database for NonCommercial purposes +only; + +b. if You include all or a substantial portion of the database +contents in a database in which You have Sui Generis Database +Rights, then the database in which You have Sui Generis Database +Rights (but not its individual contents) is Adapted Material, +including for purposes of Section 3(b); and + +c. You must comply with the conditions in Section 3(a) if You Share +all or a substantial portion of the contents of the database. + +For the avoidance of doubt, this Section 4 supplements and does not +replace Your obligations under this Public License where the Licensed +Rights include other Copyright and Similar Rights. + +Section 5 -- Disclaimer of Warranties and Limitation of Liability. + +a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE +EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS +AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF +ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, +IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, +WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR +PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, +ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT +KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT +ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. + +b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE +TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, +NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, +INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, +COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR +USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN +ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR +DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR +IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. + +c. The disclaimer of warranties and limitation of liability provided +above shall be interpreted in a manner that, to the extent +possible, most closely approximates an absolute disclaimer and +waiver of all liability. + +Section 6 -- Term and Termination. + +a. This Public License applies for the term of the Copyright and +Similar Rights licensed here. However, if You fail to comply with +this Public License, then Your rights under this Public License +terminate automatically. + +b. Where Your right to use the Licensed Material has terminated under +Section 6(a), it reinstates: + + 1. automatically as of the date the violation is cured, provided + it is cured within 30 days of Your discovery of the + violation; or + + 2. upon express reinstatement by the Licensor. + + For the avoidance of doubt, this Section 6(b) does not affect any + right the Licensor may have to seek remedies for Your violations + of this Public License. + +c. For the avoidance of doubt, the Licensor may also offer the +Licensed Material under separate terms or conditions or stop +distributing the Licensed Material at any time; however, doing so +will not terminate this Public License. + +d. Sections 1, 5, 6, 7, and 8 survive termination of this Public +License. + +Section 7 -- Other Terms and Conditions. + +a. The Licensor shall not be bound by any additional or different +terms or conditions communicated by You unless expressly agreed. + +b. Any arrangements, understandings, or agreements regarding the +Licensed Material not stated herein are separate from and +independent of the terms and conditions of this Public License. + +Section 8 -- Interpretation. + +a. For the avoidance of doubt, this Public License does not, and +shall not be interpreted to, reduce, limit, restrict, or impose +conditions on any use of the Licensed Material that could lawfully +be made without permission under this Public License. + +b. To the extent possible, if any provision of this Public License is +deemed unenforceable, it shall be automatically reformed to the +minimum extent necessary to make it enforceable. If the provision +cannot be reformed, it shall be severed from this Public License +without affecting the enforceability of the remaining terms and +conditions. + +c. No term or condition of this Public License will be waived and no +failure to comply consented to unless expressly agreed to by the +Licensor. + +d. Nothing in this Public License constitutes or may be interpreted +as a limitation upon, or waiver of, any privileges and immunities +that apply to the Licensor or You, including from the legal +processes of any jurisdiction or authority. + +======================================================================= + +Creative Commons is not a party to its public +licenses. Notwithstanding, Creative Commons may elect to apply one of +its public licenses to material it publishes and in those instances +will be considered the “Licensor.” The text of the Creative Commons +public licenses is dedicated to the public domain under the CC0 Public +Domain Dedication. Except for the limited purpose of indicating that +material is shared under a Creative Commons public license or as +otherwise permitted by the Creative Commons policies published at +creativecommons.org/policies, Creative Commons does not authorize the +use of the trademark "Creative Commons" or any other trademark or logo +of Creative Commons without its prior written consent including, +without limitation, in connection with any unauthorized modifications +to any of its public licenses or any other arrangements, +understandings, or agreements concerning use of licensed material. For +the avoidance of doubt, this paragraph does not form part of the +public licenses. + +Creative Commons may be contacted at creativecommons.org. From dceb9b73bf8c6127e4be1e5ed15d4aab7c4bfb34 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 11 Nov 2023 17:44:05 +0100 Subject: [PATCH 20/33] chore: rinominato file testing --- docs/{testing/README.md => it/testing.md} | 2 +- docs/{ => it}/testing/piramide.png | Bin 2 files changed, 1 insertion(+), 1 deletion(-) rename docs/{testing/README.md => it/testing.md} (99%) rename docs/{ => it}/testing/piramide.png (100%) diff --git a/docs/testing/README.md b/docs/it/testing.md similarity index 99% rename from docs/testing/README.md rename to docs/it/testing.md index 6ad63c29..624c65ae 100644 --- a/docs/testing/README.md +++ b/docs/it/testing.md @@ -7,7 +7,7 @@ Il testing è una parte fondamentale di ogni progetto software. In questo capito Esistono diversi tipi di test, ognuno con un suo scopo ben preciso. Si fa spesso riferimento alla piramide del testing, che rappresenta la proporzione tra i diversi tipi di test: -Piramide del testing +Piramide del testing Di seguito vedremo nel dettaglio i diversi tipi di test. diff --git a/docs/testing/piramide.png b/docs/it/testing/piramide.png similarity index 100% rename from docs/testing/piramide.png rename to docs/it/testing/piramide.png From c93ffb55e212851aadf920bf1ff8fd6d4f0fc8bb Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 11 Nov 2023 17:44:19 +0100 Subject: [PATCH 21/33] chore: linting --- docs/it/testing.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/it/testing.md b/docs/it/testing.md index 624c65ae..12e7258c 100644 --- a/docs/it/testing.md +++ b/docs/it/testing.md @@ -54,7 +54,7 @@ Spesso realizzare questi test è più complesso perché bisogna prima avere idea ### End-to-end test -Il test end-to-end (E2E) è una metodologia di test del software che si concentra sul test dell'intero sistema software dall'inizio alla fine, simulando scenari del mondo reale e interazioni dell'utente. Ha lo scopo di garantire che il sistema funzioni correttamente nel suo insieme e soddisfi i requisiti aziendali desiderati. A differenza degli altri tipi di test, fin ora trattati, qui il test interagisce con l'applicativo __solo__ attraverso le interfacce più esterne (Browser o Api). +Il test end-to-end (E2E) è una metodologia di test del software che si concentra sul test dell'intero sistema software dall'inizio alla fine, simulando scenari del mondo reale e interazioni dell'utente. Ha lo scopo di garantire che il sistema funzioni correttamente nel suo insieme e soddisfi i requisiti aziendali desiderati. A differenza degli altri tipi di test, fin ora trattati, qui il test interagisce con l'applicativo **solo** attraverso le interfacce più esterne (Browser o Api). E qui sta il punto. I requisiti sono essenzialmente aziendali e non tecnici. @@ -109,7 +109,7 @@ Il continuous testing è una metodologia di testing in cui i test vengono esegui ### Test-driven development Il test-driven development (TDD) è una metodologia di sviluppo software che prevede di scrivere i test prima di scrivere il codice. -La parola Test nell'acronimo è spesso mal interpretata. Il TDD non è uno strumento per testare l'applicazione, ma per far emergere il design dell'applicativo, partendo dai test che vogliamo soddisfare. Questo ci permette di rispettare il principio YAGNI (You aren't gonna need it), ovvero non scrivere codice per esigenze future, ma solo per soddisfare l'implementazione dei test da soddisfare. +La parola Test nell'acronimo è spesso mal interpretata. Il TDD non è uno strumento per testare l'applicazione, ma per far emergere il design dell'applicativo, partendo dai test che vogliamo soddisfare. Questo ci permette di rispettare il principio YAGNI (You aren't gonna need it), ovvero non scrivere codice per esigenze future, ma solo per soddisfare l'implementazione dei test da soddisfare. Il TDD inizia con la scrittura dei test prima di scrivere il codice effettivo. Il ciclo TDD - Spesso chiamato _red-green-refactor_ - è semplice ma potente: @@ -138,7 +138,7 @@ Di seguito un esmpio che descrive una semplice ricerca su Google: ``` Feature: Google Searching As a web surfer, I want to search Google, so that I can learn new things. - + Scenario: Simple Google search Given a web browser is on the Google page When the search phrase "panda" is entered From 37206ec4bc88ea449ea1a3578af17ceb5a159593 Mon Sep 17 00:00:00 2001 From: Simone Gentili Date: Sun, 19 Nov 2023 21:32:52 +0100 Subject: [PATCH 22/33] feat: piccole correzioni per rispettare le guidelines (#96) --- docs/it/testing.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/it/testing.md b/docs/it/testing.md index 12e7258c..b07f31e4 100644 --- a/docs/it/testing.md +++ b/docs/it/testing.md @@ -150,3 +150,7 @@ Feature: Google Searching La test coverage è una metrica che indica la percentuale di codice sorgente che viene eseguita (_coperta_) durante l'esecuzione dei test. Questa metrica è molto importante, in quanto permette di capire quanto il codice sorgente è stato testato. Solitamente si cerca di raggiungere una test coverage del 100%, ma questo non è sempre possibile. Inoltre, una test coverage del 100% non garantisce che il codice sorgente sia privo di bug, esattamente come una coverage del 50% non garantisce che il codice sorgente sia pieno di bug. Come in moltissimi altri aspetti della programmazione, la parola _dipende_ assume un significato molto importante. **La test coverage ci dice quanto del nostro codice si comporta come ci aspettiamo, ma non è detto che ciò che ci aspettiamo sia corretto.** + +### Ping Pong TDD + +Tendenzialmente quando si fa test driven development si è da soli davanti al proprio programma da completare e davanti alla propria tastiera. Esiste però una pratica che porta più persone a fare test driven developement insieme. Questo è un modo molto coinvolgente di applicare il tdd. Innanzi tutto necessario essere almeno in due per poterlo mettere in pratica. Le regole di questo "gioco" stanno nell'alternarsi alla tastiera. Il primo "turno" è diverso da tutti i successivi: il primo programmatore, scrive un test che fallisce, poi passa la tastiera al suo collega. Da questo e per tutti i turni successivi, il programmatore di turno deve: per prima cosa far diventare verdi i test scrivendo il codice di produzione adatto, e come seconda cosa dovra scrivere a sua volta un test rosso. Una volta che il test rosso viene scritto, il turno sarà finito e la tastiera tornerà al primo programmatgore. In pratica ad ogni turno si fan diventare verdi i test e successivamente di crea il test per far proseguire il software. \ No newline at end of file From 698e47a3f256bc51111601283aa279daee173af3 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Wed, 29 Nov 2023 14:45:03 +0100 Subject: [PATCH 23/33] chore: aggiunta nota sul ping pong tdd nel punto corretto --- docs/it/testing.md | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/docs/it/testing.md b/docs/it/testing.md index b07f31e4..9ddb3dcc 100644 --- a/docs/it/testing.md +++ b/docs/it/testing.md @@ -123,6 +123,19 @@ Un altro vantaggio del TDD è che si sta automaticamente creando una documentazi Non c'è rosa senza spine! Il TDD non è una pratica facile da padroneggiare. Un ottimo modo per iniziare, è l'esercitazione attraverso esercizi mirati, chiamati kata. Piccolo spoiler, qeusti esercizi vengono spesso usati in fase di colloghio. +**Ping Pong TDD** + +Tendenzialmente quando si fa Test Driven Development si è da soli davanti al proprio programma da completare e davanti alla propria tastiera. Esiste però una pratica che porta più persone a fare Test Driven Development insieme che prende il nome di _Ping Pong TDD_. +Questo è un metodo molto coinvolgente di applicare il TDD. + +Come accennato, è un pre-requisito del metodo essere almeno in due. + +Le regole di questo _gioco_ si basano sull'alternarsi alla tastiera quando si scrive un test. Il primo "turno" è diverso da tutti i successivi: chi si trova per primo alla tastiera scrive un test che fallisce, poi passa la tastiera al suo pair. Da questo e per tutti i turni successivi, quando una persona inizia il proprio turno deve: +- Far diventare verdi i test scrivendo il codice di produzione adatto. +- Scrivere un test rosso. + +Una volta che il test rosso viene scritto, il turno sarà finito e la tastiera tornerà a chi ha iniziato la sessione di ping pong. In pratica ad ogni turno l'obiettivo è far passare i test e successivamente crearne di nuovi fino al completamento del software. + ### Behavior-driven development Il behavior-driven development (BDD) è una metodologia che permette di esplicitare i requisiti funzionali, tramite test. Questo permette una maggior comprensione degli sviluppi, creando un dialogo tra Product Owner e Dev Team, con i test come lingua comune. @@ -149,8 +162,4 @@ Feature: Google Searching La test coverage è una metrica che indica la percentuale di codice sorgente che viene eseguita (_coperta_) durante l'esecuzione dei test. Questa metrica è molto importante, in quanto permette di capire quanto il codice sorgente è stato testato. Solitamente si cerca di raggiungere una test coverage del 100%, ma questo non è sempre possibile. Inoltre, una test coverage del 100% non garantisce che il codice sorgente sia privo di bug, esattamente come una coverage del 50% non garantisce che il codice sorgente sia pieno di bug. Come in moltissimi altri aspetti della programmazione, la parola _dipende_ assume un significato molto importante. -**La test coverage ci dice quanto del nostro codice si comporta come ci aspettiamo, ma non è detto che ciò che ci aspettiamo sia corretto.** - -### Ping Pong TDD - -Tendenzialmente quando si fa test driven development si è da soli davanti al proprio programma da completare e davanti alla propria tastiera. Esiste però una pratica che porta più persone a fare test driven developement insieme. Questo è un modo molto coinvolgente di applicare il tdd. Innanzi tutto necessario essere almeno in due per poterlo mettere in pratica. Le regole di questo "gioco" stanno nell'alternarsi alla tastiera. Il primo "turno" è diverso da tutti i successivi: il primo programmatore, scrive un test che fallisce, poi passa la tastiera al suo collega. Da questo e per tutti i turni successivi, il programmatore di turno deve: per prima cosa far diventare verdi i test scrivendo il codice di produzione adatto, e come seconda cosa dovra scrivere a sua volta un test rosso. Una volta che il test rosso viene scritto, il turno sarà finito e la tastiera tornerà al primo programmatgore. In pratica ad ogni turno si fan diventare verdi i test e successivamente di crea il test per far proseguire il software. \ No newline at end of file +**La test coverage ci dice quanto del nostro codice si comporta come ci aspettiamo, ma non è detto che ciò che ci aspettiamo sia corretto.** \ No newline at end of file From 192e12f7ec17d6151e9b6c6c9cc1a0cbe83e8fd1 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Wed, 29 Nov 2023 14:45:13 +0100 Subject: [PATCH 24/33] chore: lint --- docs/it/testing.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/it/testing.md b/docs/it/testing.md index 9ddb3dcc..7c0d1b4d 100644 --- a/docs/it/testing.md +++ b/docs/it/testing.md @@ -131,6 +131,7 @@ Questo è un metodo molto coinvolgente di applicare il TDD. Come accennato, è un pre-requisito del metodo essere almeno in due. Le regole di questo _gioco_ si basano sull'alternarsi alla tastiera quando si scrive un test. Il primo "turno" è diverso da tutti i successivi: chi si trova per primo alla tastiera scrive un test che fallisce, poi passa la tastiera al suo pair. Da questo e per tutti i turni successivi, quando una persona inizia il proprio turno deve: + - Far diventare verdi i test scrivendo il codice di produzione adatto. - Scrivere un test rosso. @@ -162,4 +163,4 @@ Feature: Google Searching La test coverage è una metrica che indica la percentuale di codice sorgente che viene eseguita (_coperta_) durante l'esecuzione dei test. Questa metrica è molto importante, in quanto permette di capire quanto il codice sorgente è stato testato. Solitamente si cerca di raggiungere una test coverage del 100%, ma questo non è sempre possibile. Inoltre, una test coverage del 100% non garantisce che il codice sorgente sia privo di bug, esattamente come una coverage del 50% non garantisce che il codice sorgente sia pieno di bug. Come in moltissimi altri aspetti della programmazione, la parola _dipende_ assume un significato molto importante. -**La test coverage ci dice quanto del nostro codice si comporta come ci aspettiamo, ma non è detto che ciò che ci aspettiamo sia corretto.** \ No newline at end of file +**La test coverage ci dice quanto del nostro codice si comporta come ci aspettiamo, ma non è detto che ciò che ci aspettiamo sia corretto.** From ec9018d389caae73a8f1f9dd7122306a7170ba4e Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Fri, 1 Dec 2023 10:41:28 +0100 Subject: [PATCH 25/33] chore: corretto typo --- docs/it/testing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/testing.md b/docs/it/testing.md index 7c0d1b4d..2ceb9e36 100644 --- a/docs/it/testing.md +++ b/docs/it/testing.md @@ -121,7 +121,7 @@ Il TDD inizia con la scrittura dei test prima di scrivere il codice effettivo. I Un altro vantaggio del TDD è che si sta automaticamente creando una documentazione tecnica. Guardando la descrizione dei test, è facile comprendere come debba comportarsi l'applicazione. -Non c'è rosa senza spine! Il TDD non è una pratica facile da padroneggiare. Un ottimo modo per iniziare, è l'esercitazione attraverso esercizi mirati, chiamati kata. Piccolo spoiler, qeusti esercizi vengono spesso usati in fase di colloghio. +Non c'è rosa senza spine! Il TDD non è una pratica facile da padroneggiare. Un ottimo modo per iniziare, è l'esercitazione attraverso esercizi mirati, chiamati kata. Piccolo spoiler, questi esercizi vengono spesso usati in fase di colloquio. **Ping Pong TDD** From 828df746d1f5f823ec21e3add6294da59906c26a Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Tue, 5 Dec 2023 17:19:25 +0100 Subject: [PATCH 26/33] chore: review Co-authored-by: Simone Gentili Co-authored-by: Angelo Cassano --- docs/it/testing.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/it/testing.md b/docs/it/testing.md index 2ceb9e36..98c4a2ef 100644 --- a/docs/it/testing.md +++ b/docs/it/testing.md @@ -17,17 +17,17 @@ Il test unitario è un processo di sviluppo software in cui le parti testabili p Il punto principale è la presenza di un contesto isolato con un obiettivo. -Non dovrebbe avere dipendenze, se presenti queste dovrebbero essere messe sotto mock quando possibile. +Non dovrebbe avere dipendenze, se presenti queste dovrebbero essere messe sotto mock quando possibile. Un mock è letteralmente un classe che finge di essere la classe che vogliamo mockare. Questo è importante perché ci permette di simulare tutti i comportamenti che potrebbe avere la dipendenza senza dipendere direttamente da essa. -Coverage: Solitamente gli unit test permettono di raggiungere alti livelli di code coverage proprio per via della loro granularità. +Coverage: Solitamente gli unit test permettono di raggiungere alti livelli di code coverage proprio per via della loro granularità. Più righe di codice sono coperte da un test, più è facile raggiungere la coverage al 100% -Solitamente i problemi nati negli unit test sono più facili da correggere perché riguardano piccole porzioni di codice e molti test sono riutilizzabili anche in altri progetti se si usa codice condiviso. +Solitamente i problemi rilevabili negli unit test sono più facili da correggere perché riguardano piccole porzioni di codice e molti test sono riutilizzabili anche in altri progetti se si usa codice condiviso. D'altro canto, se i test sono scritti male o non hanno una buona coverage, danno falsa sicurezza e non prevengono i bug, inoltre impiegano tanto tempo ad essere scritti. ### Integration test -Il test di integrazione è una tecnica di test del software che si concentra sul test delle interazioni e dell'integrazione tra più componenti o moduli di un sistema software. Ha lo scopo di verificare che i diversi componenti, quando combinati, funzionino correttamente e producano i risultati attesi. +Il test di integrazione è una tecnica di test del software che ha come obiettivo quello di testare le integrazioni tra più componenti o moduli di un sistema software. Ha lo scopo di verificare che i diversi componenti, quando combinati, funzionino correttamente e producano i risultati attesi. Concetti principali: @@ -38,12 +38,12 @@ Concetti principali: Tipologie di test: - **Big-bang**: Si creano decine, centinaia, migliaia di test in base alla dimensione della codebase. Si testa tutto, tutto assieme. Solitamente il tutto viene fatto in un singolo integration test, o in pochissimi. Funziona per codebase ridotte. -- **Top-down testing**: Approccio incrementale, si parte dai moduli ad altissimo livello (Controller nel caso di un MVC) e si scende al livello più basso (Se si utilizzano i fat model si arriva anche fino a lì). Funziona per codebase grosse, iniziare è più tosta ma ha più impatto, pian piano diventa sempre più facile perché le parti "sopra" sono già state testate. +- **Top-down testing**: Approccio incrementale, si parte dai moduli ad altissimo livello (Controller nel caso di un MVC) e si scende al livello più basso (Se si utilizzano i fat model si arriva anche fino a lì). Funziona per codebase grosse, iniziare è più complesso ma ha più impatto, pian piano diventa sempre più facile perché i livelli superiori sono già stati testati. - **Bottom-up testing**: Approccio incrementale al contrario. Si parte da sotto e si va in alto. Anche qui parliamo di grosse codebase, iniziare è più facile ma ha meno impatto, proseguendo anche qui diventa sempre più facile perché l’impalcatura sotto funziona. - **Sandwich** o **Hybrid Testing**: Combinazione dei due approcci sopra basati su un planning di priorità. Quando si lavora in team più o meno grandi non sempre ci si può assicurare che quanto sviluppato da una parte del team comunichi correttamente con quanto sviluppato da un’altra parte del team, questi test sono fondamentali in questi contesti, inoltre è facile individuare e correggere il comportamento di una specifica funzione (Tramite unit test o tramite semplice attenzione quando si sviluppa), più difficile è notare eventuali differenze nel modo in cui i componenti di un’applicazione interagiscono tra di loro. I test di integrazione sono OTTIMI per garantire questa sicurezza. -Infine, l’integrazione tra componenti non è solo da intendersi come "corretta comunicazione e scambio di informazioni tra le parti" ma anche "corretta gestione degli errori". In definitiva, se so che quei due componenti funzionano assieme e ho scritto correttamente i test dormo sonni tranquilli. +Infine, l’integrazione tra componenti non è solo da intendersi come "corretta comunicazione e scambio di informazioni tra le parti" ma anche "corretta gestione degli errori". In definitiva, se due o più componenti funzionano assieme e i test sono stati scritti correttamente, abbiamo quasi l'assoluta certezza del loro funzionamento combinato. D'altro canto è complesso realizzare dei test di integrazione e mantenerli nel tempo per via dell’evoluzione naturale del software su cui si lavora. @@ -60,7 +60,7 @@ E qui sta il punto. I requisiti sono essenzialmente aziendali e non tecnici. Nei test E2E, l'intera applicazione o sistema viene testato in un modo che imita il modo in cui verrebbe utilizzato dagli utenti finali. Implica la simulazione delle interazioni dell'utente, l'inserimento dei dati e la convalida degli output previsti su più componenti, moduli e livelli del sistema. -Anche qui parliamo di contesto e obiettivi, ma chiaramente non sono più “specifici” di per se, perché testate “specificatamente” un flusso di pagamento coinvolge centinaia di parti. Inoltre, vista la complessità di realizzare questi test, solitamente si usano strumenti che perlomeno automatizzino alcune parti del processo, come un live recording via estensione del browser. +Anche qui parliamo di contesto e obiettivi, ma chiaramente non sono più “specifici” di per se perché, ad esempio, testare “specificatamente” un flusso di pagamento coinvolge centinaia di parti. Inoltre, vista la complessità rilevata nel realizzare questi test, solitamente si usano strumenti che perlomeno automatizzino alcune parti del processo, come un live recording via estensione del browser. A differenza degli altri tipi di test, qui possiamo verificare se l’esigenza non funzionale, e quindi di business, sia rispecchiata nel comportamento della piattaforma. @@ -109,7 +109,7 @@ Il continuous testing è una metodologia di testing in cui i test vengono esegui ### Test-driven development Il test-driven development (TDD) è una metodologia di sviluppo software che prevede di scrivere i test prima di scrivere il codice. -La parola Test nell'acronimo è spesso mal interpretata. Il TDD non è uno strumento per testare l'applicazione, ma per far emergere il design dell'applicativo, partendo dai test che vogliamo soddisfare. Questo ci permette di rispettare il principio YAGNI (You aren't gonna need it), ovvero non scrivere codice per esigenze future, ma solo per soddisfare l'implementazione dei test da soddisfare. +La parola Test nell'acronimo è spesso mal interpretata. Il TDD non è uno strumento per testare l'applicazione, ma per far emergere il design dell'applicativo partendo dagli obiettivi, sottoforma di test, che vogliamo soddisfare. Questo ci permette di rispettare il principio YAGNI (You aren't gonna need it), ovvero non scrivere codice per esigenze future, ma solo per soddisfare l'implementazione dei test da soddisfare. Il TDD inizia con la scrittura dei test prima di scrivere il codice effettivo. Il ciclo TDD - Spesso chiamato _red-green-refactor_ - è semplice ma potente: @@ -121,7 +121,7 @@ Il TDD inizia con la scrittura dei test prima di scrivere il codice effettivo. I Un altro vantaggio del TDD è che si sta automaticamente creando una documentazione tecnica. Guardando la descrizione dei test, è facile comprendere come debba comportarsi l'applicazione. -Non c'è rosa senza spine! Il TDD non è una pratica facile da padroneggiare. Un ottimo modo per iniziare, è l'esercitazione attraverso esercizi mirati, chiamati kata. Piccolo spoiler, questi esercizi vengono spesso usati in fase di colloquio. +Non c'è rosa senza spine! Il TDD non è una pratica facile da padroneggiare. Un ottimo modo per iniziare, è l'esercitazione attraverso esercizi mirati, chiamati kata, spesso usati in sede di colloquio. **Ping Pong TDD** @@ -161,6 +161,6 @@ Feature: Google Searching ## Test Coverage -La test coverage è una metrica che indica la percentuale di codice sorgente che viene eseguita (_coperta_) durante l'esecuzione dei test. Questa metrica è molto importante, in quanto permette di capire quanto il codice sorgente è stato testato. Solitamente si cerca di raggiungere una test coverage del 100%, ma questo non è sempre possibile. Inoltre, una test coverage del 100% non garantisce che il codice sorgente sia privo di bug, esattamente come una coverage del 50% non garantisce che il codice sorgente sia pieno di bug. Come in moltissimi altri aspetti della programmazione, la parola _dipende_ assume un significato molto importante. +La test coverage è una metrica che indica la percentuale di codice sorgente che viene eseguita (_coperta_) durante l'esecuzione dei test. Questa metrica è molto importante, in quanto permette di capire quanto il codice sorgente è stato testato. Solitamente si cerca di raggiungere una test coverage del 100%, ma questo non è sempre possibile. Inoltre, una test coverage del 100% non garantisce che il codice sorgente sia privo di bug, esattamente come non lo garantisce una coverage del 50%. Come in moltissimi altri aspetti della programmazione, la parola _dipende_ assume un significato molto importante. **La test coverage ci dice quanto del nostro codice si comporta come ci aspettiamo, ma non è detto che ciò che ci aspettiamo sia corretto.** From bf055729e39307fd4561d4df0f2fb79c04ca5330 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Tue, 5 Dec 2023 17:21:57 +0100 Subject: [PATCH 27/33] chore: aggiunti riferimenti a golden e contract testing Co-authored-by: Angelo Cassano --- docs/it/testing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/testing.md b/docs/it/testing.md index 98c4a2ef..905d19ff 100644 --- a/docs/it/testing.md +++ b/docs/it/testing.md @@ -80,7 +80,7 @@ Esistono diverse tipologie di test, ognuna con un suo scopo ben preciso. Vediamo - **Security testing**: Il test di sicurezza è un tipo di test in cui il target è la sicurezza del sistema. Il sistema viene infatti testato rispetto ai requisiti di sicurezza, garantendo che questi siano adeguatamente soddisfatti dall'applicazione. - **Regression testing**: Il test di regressione è un tipo di test in cui il target è la regressione del sistema. Il sistema viene infatti testato rispetto ai requisiti di regressione, garantendo che questi siano adeguatamente soddisfatti dall'applicazione. -Esistono molte altre tipologie di test, come _compatibility testing_, _acceptance testing_, _exploratory testing_, ma queste sono le più comuni. +Esistono molte altre tipologie di test, come _compatibility testing_, _acceptance testing_, _exploratory testing_, _golden testing_, _contract testing_, ma queste sono le più comuni. ## Tecniche di test From 7b1fecc5b7d3c635bbf8ca7683a36e6812b58e28 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 16 Dec 2023 17:30:12 +0100 Subject: [PATCH 28/33] chore: rivista la forma di alcune parti + continuous integration + over-testing --- docs/it/testing.md | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/docs/it/testing.md b/docs/it/testing.md index 905d19ff..7d46b0a2 100644 --- a/docs/it/testing.md +++ b/docs/it/testing.md @@ -6,10 +6,10 @@ Il testing è una parte fondamentale di ogni progetto software. In questo capito Esistono diversi tipi di test, ognuno con un suo scopo ben preciso. -Si fa spesso riferimento alla piramide del testing, che rappresenta la proporzione tra i diversi tipi di test: +Si fa spesso riferimento alla piramide del testing, che rappresenta la proporzione tra di essi: Piramide del testing -Di seguito vedremo nel dettaglio i diversi tipi di test. +Nel resto del capitolo li vedremo nel dettaglio. ### Unit test @@ -106,6 +106,8 @@ L'automated testing è una metodologia di testing in cui i test vengono eseguiti Il continuous testing è una metodologia di testing in cui i test vengono eseguiti automaticamente ad ogni commit o ad ogni modifica del codice sorgente. +Solitamente viene utilizzato in congiunzione con il concetto di _continuous integration_, ovvero una metodologia di sviluppo software in cui i membri di un team integrano il proprio lavoro frequentemente, generalmente ogni giorno o più volte al giorno. Ogni integrazione viene verificata da un'automazione di build (compilazione) che permette di individuare errori di integrazione il prima possibile. + ### Test-driven development Il test-driven development (TDD) è una metodologia di sviluppo software che prevede di scrivere i test prima di scrivere il codice. @@ -139,7 +141,7 @@ Una volta che il test rosso viene scritto, il turno sarà finito e la tastiera t ### Behavior-driven development -Il behavior-driven development (BDD) è una metodologia che permette di esplicitare i requisiti funzionali, tramite test. Questo permette una maggior comprensione degli sviluppi, creando un dialogo tra Product Owner e Dev Team, con i test come lingua comune. +Il behavior-driven development (BDD) è una metodologia che permette di esplicitare i requisiti funzionali, tramite test. Questo permette una maggior comprensione degli sviluppi, creando un dialogo tra Product Team e Dev Team, con i test come lingua comune. Questo tipo di test viene scritto con un linguaggio chiamato _gherkins_, composto da Feature e vari scenari. Ogni scenario è composto da: @@ -147,7 +149,7 @@ Questo tipo di test viene scritto con un linguaggio chiamato _gherkins_, compost 2. When: un'azione sotto test. 3. Then: una condizione da verificare. -Di seguito un esmpio che descrive una semplice ricerca su Google: +Di seguito un esempio che descrive una semplice ricerca su Google: ``` Feature: Google Searching @@ -161,6 +163,10 @@ Feature: Google Searching ## Test Coverage -La test coverage è una metrica che indica la percentuale di codice sorgente che viene eseguita (_coperta_) durante l'esecuzione dei test. Questa metrica è molto importante, in quanto permette di capire quanto il codice sorgente è stato testato. Solitamente si cerca di raggiungere una test coverage del 100%, ma questo non è sempre possibile. Inoltre, una test coverage del 100% non garantisce che il codice sorgente sia privo di bug, esattamente come non lo garantisce una coverage del 50%. Come in moltissimi altri aspetti della programmazione, la parola _dipende_ assume un significato molto importante. +La test coverage è una metrica che indica la percentuale di codice sorgente che viene eseguita (_coperta_) durante l'esecuzione dei test. Questa metrica è molto importante, in quanto permette di capire quanto il codice sorgente è stato testato. Solitamente si cerca di raggiungere una test coverage del 100%, ma questo non è sempre possibile, oltre che non necessario. Una test coverage del 100% non garantisce che il codice sorgente sia privo di bug, esattamente come non lo garantisce una coverage del 50%. Come in moltissimi altri aspetti della programmazione, la parola _dipende_ assume un significato molto importante. **La test coverage ci dice quanto del nostro codice si comporta come ci aspettiamo, ma non è detto che ciò che ci aspettiamo sia corretto.** + +### Over-testing + +Altra nota importante è relativa alla _coverage 100%_: solitamente si sconsiglia l'adozione di una coverage così alta in quanto si rischia di incorrere in un fenomeno chiamato _over-testing_, nel quale si testano tutte le possibili casistiche, anche quelle che non hanno senso e che impiegano molto tempo ad essere scritte. Questo fenomeno è molto pericoloso, in quanto si rischia di scrivere codice per il mero raggiungimento di un numero, la coverage appunto, che non aggiunge valore al prodotto e che non soddisfa alcun requisito funzionale o non funzionale. \ No newline at end of file From 35f8d67596f68fb65610f823f32581c351f4b283 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 16 Dec 2023 17:30:20 +0100 Subject: [PATCH 29/33] chore: linting --- docs/it/testing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/testing.md b/docs/it/testing.md index 7d46b0a2..4c641999 100644 --- a/docs/it/testing.md +++ b/docs/it/testing.md @@ -169,4 +169,4 @@ La test coverage è una metrica che indica la percentuale di codice sorgente che ### Over-testing -Altra nota importante è relativa alla _coverage 100%_: solitamente si sconsiglia l'adozione di una coverage così alta in quanto si rischia di incorrere in un fenomeno chiamato _over-testing_, nel quale si testano tutte le possibili casistiche, anche quelle che non hanno senso e che impiegano molto tempo ad essere scritte. Questo fenomeno è molto pericoloso, in quanto si rischia di scrivere codice per il mero raggiungimento di un numero, la coverage appunto, che non aggiunge valore al prodotto e che non soddisfa alcun requisito funzionale o non funzionale. \ No newline at end of file +Altra nota importante è relativa alla _coverage 100%_: solitamente si sconsiglia l'adozione di una coverage così alta in quanto si rischia di incorrere in un fenomeno chiamato _over-testing_, nel quale si testano tutte le possibili casistiche, anche quelle che non hanno senso e che impiegano molto tempo ad essere scritte. Questo fenomeno è molto pericoloso, in quanto si rischia di scrivere codice per il mero raggiungimento di un numero, la coverage appunto, che non aggiunge valore al prodotto e che non soddisfa alcun requisito funzionale o non funzionale. From fce93233d8892b504a6a582106cce0dd5d144576 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Tue, 19 Dec 2023 09:17:46 +0100 Subject: [PATCH 30/33] chore: inseriti suggerimenti di sistella Co-authored-by: sistella <56387955+sistella@users.noreply.github.com> --- docs/it/testing.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/it/testing.md b/docs/it/testing.md index 4c641999..cfd7fa9b 100644 --- a/docs/it/testing.md +++ b/docs/it/testing.md @@ -13,21 +13,21 @@ Nel resto del capitolo li vedremo nel dettaglio. ### Unit test -Il test unitario è un processo di sviluppo software in cui le parti testabili più piccole di un'applicazione, denominate unità, vengono esaminate individualmente per verificarne il corretto funzionamento. Chi sviluppa e talvolta il personale del controllo qualità completano i test unitari durante il processo di sviluppo. Per unità solitamente si intende una funzione o una piccola serie di funzioni i cui comportamenti sono strettamente legati. +Il test unitario è un processo di sviluppo software in cui le parti testabili più piccole di un'applicazione, denominate unità, vengono esaminate individualmente per verificarne il corretto funzionamento. Chi sviluppa, o chi si occupa del controllo qualità del software, completa i test unitari durante il processo di sviluppo. Per unità solitamente si intende una funzione o una piccola serie di funzioni i cui comportamenti sono strettamente legati. Il punto principale è la presenza di un contesto isolato con un obiettivo. -Non dovrebbe avere dipendenze, se presenti queste dovrebbero essere messe sotto mock quando possibile. Un mock è letteralmente un classe che finge di essere la classe che vogliamo mockare. Questo è importante perché ci permette di simulare tutti i comportamenti che potrebbe avere la dipendenza senza dipendere direttamente da essa. +L'unità che ci si appresta a testare non dovrebbe avere _dipendenze_, ossia richiamare codice di altre unità. Quando ciò accade, il codice richiamato (la dipendenza) dovrebbe essere _messa sotto mock_, cioè essere sostituito, nel contesto dello unit test, da una funzione che ne fa le veci. Questa funzione, denominata appunto **mock**, ci permette di simulare tutti i comportamenti che potrebbe avere la dipendenza senza dipendere direttamente da essa. -Coverage: Solitamente gli unit test permettono di raggiungere alti livelli di code coverage proprio per via della loro granularità. Più righe di codice sono coperte da un test, più è facile raggiungere la coverage al 100% +Coverage: Solitamente gli unit test permettono di raggiungere alti livelli di code coverage proprio per via della loro granularità. Per Coverage si intende infatti la percentuale di righe di codice testate sul totale. Solitamente i problemi rilevabili negli unit test sono più facili da correggere perché riguardano piccole porzioni di codice e molti test sono riutilizzabili anche in altri progetti se si usa codice condiviso. -D'altro canto, se i test sono scritti male o non hanno una buona coverage, danno falsa sicurezza e non prevengono i bug, inoltre impiegano tanto tempo ad essere scritti. +D'altro canto, se i test sono scritti male o non forniscono una buona coverage, danno falsa sicurezza e non prevengono i bug, e il (tanto) tempo impiegato a scriverli risulta inutile. ### Integration test -Il test di integrazione è una tecnica di test del software che ha come obiettivo quello di testare le integrazioni tra più componenti o moduli di un sistema software. Ha lo scopo di verificare che i diversi componenti, quando combinati, funzionino correttamente e producano i risultati attesi. +Il test di integrazione è una tecnica di test del software che ha come obiettivo quello di testare più componenti o moduli di un sistema software insieme. Ha lo scopo di verificare che i diversi componenti, quando combinati, funzionino correttamente e producano i risultati attesi. Concetti principali: @@ -42,7 +42,7 @@ Tipologie di test: - **Bottom-up testing**: Approccio incrementale al contrario. Si parte da sotto e si va in alto. Anche qui parliamo di grosse codebase, iniziare è più facile ma ha meno impatto, proseguendo anche qui diventa sempre più facile perché l’impalcatura sotto funziona. - **Sandwich** o **Hybrid Testing**: Combinazione dei due approcci sopra basati su un planning di priorità. -Quando si lavora in team più o meno grandi non sempre ci si può assicurare che quanto sviluppato da una parte del team comunichi correttamente con quanto sviluppato da un’altra parte del team, questi test sono fondamentali in questi contesti, inoltre è facile individuare e correggere il comportamento di una specifica funzione (Tramite unit test o tramite semplice attenzione quando si sviluppa), più difficile è notare eventuali differenze nel modo in cui i componenti di un’applicazione interagiscono tra di loro. I test di integrazione sono OTTIMI per garantire questa sicurezza. +Quando si lavora in team, più o meno grandi, non sempre ci si può assicurare che quanto sviluppato da una parte del team comunichi correttamente con quanto sviluppato da un’altra parte del team: gli Integration test sono fondamentali in questi contesti. Inoltre, se è facile individuare e correggere il comportamento di una specifica funzione (tramite unit test o tramite semplice attenzione quando si sviluppa), più difficile è notare eventuali differenze nel modo in cui i componenti di un’applicazione interagiscono tra di loro. I test di integrazione sono OTTIMI per garantire questa sicurezza. Infine, l’integrazione tra componenti non è solo da intendersi come "corretta comunicazione e scambio di informazioni tra le parti" ma anche "corretta gestione degli errori". In definitiva, se due o più componenti funzionano assieme e i test sono stati scritti correttamente, abbiamo quasi l'assoluta certezza del loro funzionamento combinato. D'altro canto è complesso realizzare dei test di integrazione e mantenerli nel tempo per via dell’evoluzione naturale del software su cui si lavora. @@ -68,7 +68,7 @@ Infine, a differenza degli altri tipi di test trattati, qui vediamo all’atto p Ricreando scenari realistici, abbiamo modo di avere una sicurezza “definitiva” (tra molte virgolette) del comportamento della piattaforma. -D'altro canto, è difficile prevedere e analizzare quante farne e cosa testare. Inoltre il test è più lungo da scrivere perché mentre per un integration test basta cambiare un flag, un e2e deve probabilmente essere riscritto perché ha flussi differenti per giungere alla stessa conclusione. +D'altro canto, è difficile prevedere e analizzare quante farne e cosa testare. Inoltre il test è più lungo da scrivere perché mentre per un integration test basta cambiare un flag per ottenere un flusso diverso, un test e2e deve probabilmente essere riscritto perché ha flussi differenti per giungere alla stessa conclusione. ## Tipologie di test From 2bf1e4e709a3ebf5877e425cefd3eb2ee0033aa1 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Tue, 19 Dec 2023 10:31:12 +0100 Subject: [PATCH 31/33] chore: suggerimento TDD Co-authored-by: sistella <56387955+sistella@users.noreply.github.com> --- docs/it/testing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/testing.md b/docs/it/testing.md index cfd7fa9b..377adc2a 100644 --- a/docs/it/testing.md +++ b/docs/it/testing.md @@ -50,7 +50,7 @@ D'altro canto è complesso realizzare dei test di integrazione e mantenerli nel Rispetto agli unit test, infatti, è più complicato trovare gli errori essendo più ad ampio spettro. Molto complesso individuare tutte le integrazioni che ha senso testare. La coverage al 100% è infatti inverosimile in progetti grossi. -Spesso realizzare questi test è più complesso perché bisogna prima avere idea della codebase sottostante, a prescindere che si lavori in TDD o meno. +Spesso realizzare questi test è più complesso perché bisogna prima avere idea della codebase sottostante, a prescindere che si lavori in TDD (Test Driven Development - vedi paragrafo successivo) o meno. ### End-to-end test From 66bffdcf614616b668f0a2566af9c8b1523d2404 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 23 Dec 2023 11:49:35 +0100 Subject: [PATCH 32/33] chore: applicata revisione --- docs/it/testing.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/it/testing.md b/docs/it/testing.md index 377adc2a..1642c501 100644 --- a/docs/it/testing.md +++ b/docs/it/testing.md @@ -19,7 +19,7 @@ Il punto principale è la presenza di un contesto isolato con un obiettivo. L'unità che ci si appresta a testare non dovrebbe avere _dipendenze_, ossia richiamare codice di altre unità. Quando ciò accade, il codice richiamato (la dipendenza) dovrebbe essere _messa sotto mock_, cioè essere sostituito, nel contesto dello unit test, da una funzione che ne fa le veci. Questa funzione, denominata appunto **mock**, ci permette di simulare tutti i comportamenti che potrebbe avere la dipendenza senza dipendere direttamente da essa. -Coverage: Solitamente gli unit test permettono di raggiungere alti livelli di code coverage proprio per via della loro granularità. Per Coverage si intende infatti la percentuale di righe di codice testate sul totale. +Parliamo anche del concetto di _coverage_: Solitamente gli unit test permettono di raggiungere alti livelli di code coverage proprio per via della loro granularità. Per Coverage si intende infatti la percentuale di righe di codice testate sul totale. Solitamente i problemi rilevabili negli unit test sono più facili da correggere perché riguardano piccole porzioni di codice e molti test sono riutilizzabili anche in altri progetti se si usa codice condiviso. @@ -58,9 +58,9 @@ Il test end-to-end (E2E) è una metodologia di test del software che si concentr E qui sta il punto. I requisiti sono essenzialmente aziendali e non tecnici. -Nei test E2E, l'intera applicazione o sistema viene testato in un modo che imita il modo in cui verrebbe utilizzato dagli utenti finali. Implica la simulazione delle interazioni dell'utente, l'inserimento dei dati e la convalida degli output previsti su più componenti, moduli e livelli del sistema. +Nei test E2E, l'intera applicazione o sistema viene testato in un modo che imiti il modo in cui verrebbe utilizzato dagli utenti finali. Implica la simulazione delle interazioni dell'utente, l'inserimento dei dati e la convalida degli output previsti su più componenti, moduli e livelli del sistema. -Anche qui parliamo di contesto e obiettivi, ma chiaramente non sono più “specifici” di per se perché, ad esempio, testare “specificatamente” un flusso di pagamento coinvolge centinaia di parti. Inoltre, vista la complessità rilevata nel realizzare questi test, solitamente si usano strumenti che perlomeno automatizzino alcune parti del processo, come un live recording via estensione del browser. +Anche qui parliamo di contesto e obiettivi, ma chiaramente non sono più “specifici” di per sé perché, ad esempio, testare “specificatamente” un flusso di pagamento coinvolge centinaia di parti. Inoltre, vista la complessità rilevata nel realizzare questi test, solitamente si usano strumenti che perlomeno automatizzino alcune parti del processo, come un live recording via estensione del browser. A differenza degli altri tipi di test, qui possiamo verificare se l’esigenza non funzionale, e quindi di business, sia rispecchiata nel comportamento della piattaforma. @@ -96,22 +96,22 @@ Di solito queste tre tecniche vengono utilizzate per individuare eventuali falle ### Manual testing -Il manual testing è una metodologia di testing in cui i test vengono eseguiti manualmente dalla figura del tester. Questo approccio ha diversi svantaggi e solitamente viene utilizzato solo per testare le funzionalità più critiche del sistema quando non è possibile automatizzare i test. Questa metodologia viene chiamata anche _explorative testing_, tramite la quale si prova a rompere l'applicazione creando scenari difficilmente automatizzabili e scrivendo di conseguenza i test. +Il manual testing è una metodologia in cui i test vengono eseguiti manualmente dalla figura del tester. Questo approccio ha diversi svantaggi e solitamente viene utilizzato solo per testare le funzionalità più critiche del sistema quando non è possibile automatizzare i test. Questa metodologia viene chiamata anche _explorative testing_, tramite la quale si prova a rompere l'applicazione creando scenari difficilmente automatizzabili e scrivendo di conseguenza i test. ### Automated testing -L'automated testing è una metodologia di testing in cui i test vengono eseguiti automaticamente da un software. Questo approccio ha diversi vantaggi: **Ripetibilità**, **Riduzione dei costi**, **Riduzione dei tempi di sviluppo**. +L'automated testing è una metodologia in cui i test vengono eseguiti automaticamente da un software. Questo approccio ha diversi vantaggi: **Ripetibilità**, **Riduzione dei costi**, **Riduzione dei tempi di sviluppo**. ### Continuous testing -Il continuous testing è una metodologia di testing in cui i test vengono eseguiti automaticamente ad ogni commit o ad ogni modifica del codice sorgente. +Il continuous testing è una metodologia in cui i test vengono eseguiti automaticamente ad ogni commit o ad ogni modifica del codice sorgente. Solitamente viene utilizzato in congiunzione con il concetto di _continuous integration_, ovvero una metodologia di sviluppo software in cui i membri di un team integrano il proprio lavoro frequentemente, generalmente ogni giorno o più volte al giorno. Ogni integrazione viene verificata da un'automazione di build (compilazione) che permette di individuare errori di integrazione il prima possibile. ### Test-driven development Il test-driven development (TDD) è una metodologia di sviluppo software che prevede di scrivere i test prima di scrivere il codice. -La parola Test nell'acronimo è spesso mal interpretata. Il TDD non è uno strumento per testare l'applicazione, ma per far emergere il design dell'applicativo partendo dagli obiettivi, sottoforma di test, che vogliamo soddisfare. Questo ci permette di rispettare il principio YAGNI (You aren't gonna need it), ovvero non scrivere codice per esigenze future, ma solo per soddisfare l'implementazione dei test da soddisfare. +La parola "test" nell'acronimo è spesso mal interpretata. Il TDD non è uno strumento per testare l'applicazione, ma per far emergere il design dell'applicativo partendo dagli obiettivi, sottoforma di test, che vogliamo soddisfare. Questo ci permette di rispettare il principio YAGNI (_You aren't gonna need it_), ovvero non scrivere codice per esigenze future, ma solo per soddisfare l'implementazione dei test da soddisfare. Il TDD inizia con la scrittura dei test prima di scrivere il codice effettivo. Il ciclo TDD - Spesso chiamato _red-green-refactor_ - è semplice ma potente: @@ -123,7 +123,7 @@ Il TDD inizia con la scrittura dei test prima di scrivere il codice effettivo. I Un altro vantaggio del TDD è che si sta automaticamente creando una documentazione tecnica. Guardando la descrizione dei test, è facile comprendere come debba comportarsi l'applicazione. -Non c'è rosa senza spine! Il TDD non è una pratica facile da padroneggiare. Un ottimo modo per iniziare, è l'esercitazione attraverso esercizi mirati, chiamati kata, spesso usati in sede di colloquio. +Non c'è rosa senza spine! Il TDD non è una pratica facile da padroneggiare. Un ottimo modo per iniziare, è l'esercitazione attraverso esercizi mirati, chiamati _kata_, spesso usati in sede di colloquio. **Ping Pong TDD** From a46ce7341ec3cf22d78efd3cad8911fb02813193 Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Mon, 11 Dec 2023 22:12:23 +0100 Subject: [PATCH 33/33] fix: utilizzo di .gitattribute per utilizzare sempre newline unix like , possibile soluzione per issue #179 (#181) --- .gitattributes | 1 + 1 file changed, 1 insertion(+) create mode 100644 .gitattributes diff --git a/.gitattributes b/.gitattributes new file mode 100644 index 00000000..07764a78 --- /dev/null +++ b/.gitattributes @@ -0,0 +1 @@ +* text eol=lf \ No newline at end of file