TestMaster 🧪

Progetto accademico per il corso di Integrazione e Test di Sistemi Software (ITSS) - A.A. 2023/2024
Università degli Studi di Bari Aldo Moro

---

📋 Indice

• Descrizione
• Team
• Tecnologie
• Risultati Complessivi
• Homework 1: KebabCase Converter
• Homework 2: Even Index Finder
• Quick Start
• Struttura del Progetto
• Documentazione
• Apprendimenti

---

🎯 Descrizione

TestMaster è un progetto di testing completo che esplora diverse metodologie di test del software attraverso due case study pratici. Il progetto dimostra l'applicazione di tecniche avanzate di testing su metodi Java, con particolare attenzione a:

• Specification-Based Testing: progettazione di test basati sui requisiti
• Structural Testing: analisi della copertura del codice
• Property-Based Testing: testing automatizzato con generazione casuale di dati
• Mutation Testing: valutazione della qualità della test suite

---

👥 Team

• Laura Croce - 717847 - l.croce2@studenti.uniba.it
• Sonia Auciello - 719769 - s.auciello1@studenti.uniba.it
• Luigi Dicataldo - 718152 - l.dicataldo2@studenti.uniba.it

---

🛠️ Tecnologie Utilizzate

Tecnologia	Versione	Scopo
Java	17+	Linguaggio di programmazione
JUnit 5	5.10.0	Framework di testing
JaCoCo	0.8.11	Code coverage analysis
PITest	1.15.8	Mutation testing
jqwik	1.7.4	Property-based testing
Maven	3.8+	Build automation

---

📊 Risultati Complessivi

Metrica	Homework 1	Homework 2
Line Coverage	100% (21/21)	100% (18/18)
Branch Coverage	100% (14/14)	100% (24/24)
Mutation Score	100% (9/9)	N/A
Test Cases	17	1000+
Test Duration	~80ms	~1.5s

---

📦 Homework 1: KebabCase Converter

📖 Descrizione

Testing completo del metodo convertToKebabCase() che converte stringhe in formato kebab-case sostituendo delimitatori specificati con trattini (-).

🔧 Il Metodo

public String convertToKebabCase(String input, boolean toLowerCase, char[] delimiters)

Parametri:

• input: stringa da convertire
• toLowerCase: se true, converte tutto in minuscolo
• delimiters: array di caratteri da sostituire con -

Comportamento:

• Se delimiters è null o vuoto → usa spazio come default
• Sostituisce i delimitatori con -
• Rimuove trattini multipli consecutivi
• Rimuove spazi iniziali/finali
• Restituisce null se input è null

💡 Esempi di Utilizzo

convertToKebabCase("Hello World", true, null)                    // → "hello-world"
convertToKebabCase("Another Test", false, new char[]{' '})       // → "Another-Test"
convertToKebabCase("Hello_World", true, new char[]{'_'})         // → "hello-world"
convertToKebabCase("Hello, World!", true, new char[]{' ', ','})  // → "hello-world!"
convertToKebabCase("  Spaced Out  ", true, null)                 // → "spaced-out"

🧪 Metodologie di Testing

1️⃣ Specification-Based Testing

Processo di Analisi

1. Comprensione dei Requisiti

   • Analisi approfondita delle specifiche
   • Identificazione dei parametri e output attesi
   • Documentazione del comportamento previsto

2. Identificazione delle Partizioni

   • Input String:

     • Stringa null
     • Stringa vuota ""
     • Stringa di lunghezza 1
     • Stringa di lunghezza > 1

   • toLowerCase:

     • true → conversione in minuscolo
     • false → mantiene case originale

   • delimiters:

     • null → usa spazio come default
     • Array vuoto {} → usa spazio come default
     • Array con 1 elemento
     • Array con più elementi

3. Boundary Value Analysis

   • Stringhe ai limiti (vuote, singolo carattere)
   • Array di delimitatori ai limiti (null, vuoto, 1 elemento)
   • Casi speciali (solo delimitatori, spazi multipli)

Test Case Principali (17 totali)

#	Input	toLowerCase	Delimiters	Output	Tipo
1	"Simple test"	true	{' '}	"simple-test"	Base
2	"Another Test"	false	{' '}	"Another-Test"	Base
3	"Hello World"	true	null	"hello-world"	Default
4	null	true	null	null	Edge
5	""	true	null	""	Edge
6	"A"	true	null	"a"	Boundary
7	"-----"	true	{'-'}	"-----"	Edge
8	" Spaced Out "	true	{' '}	"spaced-out"	Boundary
9	"HelloWorld"	true	{}	"helloworld"	Edge
10	"Hello_World"	true	{'_'}	"hello-world"	Base
11	"123 456 789"	true	null	"123-456-789"	Special
12	"Città e natura"	true	{' '}	"città-e-natura"	Unicode
13	"Math+Physics=Science"	true	{'+','='}	"math-physics-science"	Special
14	"(Hello), [World]!"	true	{' ',',','(',')','[',']'}	"hello-world!"	Complex
15	(Stringa 1000 char)	true	{' '}	(Output 1000 char)	Stress
16	"One…Two—Three"	true	{'.','—'}	"one-two-three"	Unicode
17	"こんにちは 世界"	true	{' '}	"こんにちは-世界"	Unicode

2️⃣ Structural Testing & Code Coverage

JaCoCo Coverage Report

╔═══════════════════════════════════════╗
║        CODE COVERAGE RESULTS          ║
╠═══════════════════════════════════════╣
║ Line Coverage:    100% (21/21)        ║
║ Branch Coverage:  100% (14/14)        ║
║ Complexity:       8                   ║
╚═══════════════════════════════════════╝

Copertura per Metodo

Metodo	Lines	Branches	Complexity
convertToKebabCase()	100%	100%	8

Analisi delle Branch

Tutte le 14 branch sono coperte:

• ✅ Input null check
• ✅ Delimiters null check
• ✅ Delimiters empty check
• ✅ toLowerCase true/false
• ✅ Special characters handling
• ✅ Trim operations
• ✅ Multiple delimiter replacement

3️⃣ Mutation Testing (PITest)

Risultati Mutation Testing

╔═══════════════════════════════════════╗
║      MUTATION TESTING RESULTS         ║
╠═══════════════════════════════════════╣
║ Mutation Score:   100% (9/9)          ║
║ Killed:           9                   ║
║ Survived:         0                   ║
║ No Coverage:      0                   ║
╚═══════════════════════════════════════╝

Mutatori Applicati

Mutatore	Mutazioni	Uccise	Sopravvissute
CONDITIONALS_BOUNDARY	1	1	0
EMPTY_RETURNS	1	1	0
FALSE_RETURNS	1	1	0
INCREMENTS	1	1	0
INVERT_NEGS	1	1	0
MATH	1	1	0
NEGATE_CONDITIONALS	1	1	0
NULL_RETURNS	1	1	0
TRUE_RETURNS	1	1	0

Cosa significa?

• Ogni mutatore modifica il codice in modo specifico
• I test devono "uccidere" le mutazioni rilevando il comportamento errato
• 100% significa che tutti i test hanno rilevato tutte le mutazioni

🐛 Bug Identificati e Risolti

Durante il testing sono emersi 2 bug nel codice originale:

Bug #1: Gestione Trattini Consecutivi

// Input
convertToKebabCase("-----", true, new char[]{'-'})

// Output Errato (prima del fix)
"-"

// Output Corretto (dopo il fix)
"-----"

// Fix Applicato
if (kebabCase.replaceAll("-", "").isEmpty()) {
    return input; // Preserva stringhe solo con delimitatori
}

Bug #2: Spazi Iniziali e Finali

// Input
convertToKebabCase(" Test ", true, null)

// Output Errato (prima del fix)
"--test--"

// Output Corretto (dopo il fix)
"test"

// Fix Applicato
input = input.trim(); // Rimuove spazi prima della conversione

---

📦 Homework 2: Even Index Finder

📖 Descrizione

Testing avanzato del metodo findEvenIndex() utilizzando Property-Based Testing con jqwik per generazione automatica e massiva di test data.

🔧 Il Metodo

public int findEvenIndex(List<Integer> numbers, boolean findFirst)

Parametri:

• numbers: lista di numeri interi da analizzare
• findFirst:
  • true → cerca il primo numero pari
  • false → cerca l'ultimo numero pari

Comportamento:

• Restituisce l'indice del numero pari trovato
• Restituisce -1 se non trova numeri pari
• Solleva IllegalArgumentException se:
  • numbers è null
  • numbers è vuota
  • numbers contiene solo numeri positivi
  • numbers contiene solo numeri negativi

💡 Esempi di Utilizzo

findEvenIndex([1, 2, 3, 4, 5], true)     // → 1 (indice di 2)
findEvenIndex([1, 2, 3, 4, 5], false)    // → 3 (indice di 4)
findEvenIndex([1, 3, 5, 7], true)        // → -1 (nessun pari)
findEvenIndex([1, 3, 5, 7], false)       // → -1 (nessun pari)
findEvenIndex(null, true)                 // → IllegalArgumentException
findEvenIndex([], true)                   // → IllegalArgumentException
findEvenIndex([1, 2, 3], true)            // → IllegalArgumentException (solo positivi)
findEvenIndex([-1, -2, -3], true)         // → IllegalArgumentException (solo negativi)

🧪 Property-Based Testing con jqwik

Cos'è il Property-Based Testing?

A differenza del testing tradizionale dove scrivi manualmente ogni test case, il Property-Based Testing:

1. Definisci proprietà generali che devono essere sempre vere
2. jqwik genera automaticamente centinaia/migliaia di input casuali
3. Verifica che la proprietà sia rispettata per tutti gli input
4. Se trova un errore, riduce automaticamente l'input al minimo che causa il fallimento (shrinking)

Esempio Confronto

Testing Tradizionale:

@Test
void testFirstEven() {
    assertEquals(1, findEvenIndex([1,2,3], true));
    assertEquals(2, findEvenIndex([1,3,4], true));
    assertEquals(0, findEvenIndex([2,3,4], true));
    // ... altri 10-20 casi scritti manualmente
}

Property-Based Testing:

@Property
void testFirstEven(@ForAll List<Integer> numbers, @ForAll boolean findFirst) {
    int result = findEvenIndex(numbers, findFirst);
    // jqwik testa automaticamente 1000+ combinazioni diverse!
}

Le Tre Proprietà Testate

Property 1: INVALID - Input Non Validi

@Property(generation = GenerationMode.RANDOMIZED)
void testInvalid(@ForAll("invalidLists") List<Integer> numbers, 
                 @ForAll boolean findFirst)

Proprietà: Il metodo deve sempre lanciare IllegalArgumentException per input non validi.

Input Generati:

• Liste vuote []
• Liste null
• Liste con solo numeri positivi [1, 2, 3]
• Liste con solo numeri negativi [-1, -2, -3]

Risultato Atteso: Sempre IllegalArgumentException

Test Eseguiti: 1000

---

Property 2: FAIL - Nessun Numero Pari

@Property(generation = GenerationMode.RANDOMIZED)
void testFail(@ForAll("oddsOnly") List<Integer> oddNumbers,
              @ForAll boolean findFirst)

Proprietà: Se la lista contiene solo numeri dispari, il risultato è sempre -1.

Input Generati:

• Liste di soli numeri dispari
• Dimensione: 2-100 elementi
• Range: [-99, 99]
• Garantito mix di positivi e negativi

Generatore Personalizzato:

@Provide
Arbitrary<List<Integer>> oddsOnly() {
    return Arbitraries.integers().between(-99, 99)
        .filter(n -> n % 2 != 0)  // Solo dispari
        .list().ofMinSize(2).ofMaxSize(100)
        .filter(list -> {
            boolean hasPositive = list.stream().anyMatch(n -> n > 0);
            boolean hasNegative = list.stream().anyMatch(n -> n < 0);
            return hasPositive && hasNegative;
        });
}

Risultato Atteso: Sempre -1

Test Eseguiti: 1000

Statistiche Raccolte:

Distribuzione Positivi/Negativi:
├─ Numeri Positivi: 53.8%
└─ Numeri Negativi: 46.2%

---

Property 3: PASS - Trovare Numeri Pari

@Property(generation = GenerationMode.RANDOMIZED)
void testPass(@ForAll @Size(min=20, max=50) 
              @IntRange(min=-100, max=100) List<Integer> numbers,
              @ForAll boolean findFirst)

Proprietà: Se esistono numeri pari, il metodo restituisce l'indice corretto.

Input Generati:

• Liste di 20-50 elementi
• Numeri nel range [-100, 100]
• Mix casuale di pari e dispari
• Garantito mix di positivi e negativi

Verifica:

// Metodi ausiliari per verifica
private int findFirstEven(List<Integer> numbers) {
    for (int i = 0; i < numbers.size(); i++) {
        if (numbers.get(i) % 2 == 0) return i;
    }
    return -1;
}

private int findLastEven(List<Integer> numbers) {
    for (int i = numbers.size() - 1; i >= 0; i--) {
        if (numbers.get(i) % 2 == 0) return i;
    }
    return -1;
}

// Nel test
int expected = findFirst ? findFirstEven(numbers) : findLastEven(numbers);
assertEquals(expected, actual);

Test Eseguiti: 1000

Statistiche Raccolte:

Distribuzione Pari/Dispari:
├─ Numeri Pari:    ~50%
└─ Numeri Dispari: ~50%

Dimensione Media Liste: 35 elementi
Range Effettivo: [-100, 100]

Structural Testing & Coverage

JaCoCo Coverage Report

╔═══════════════════════════════════════╗
║        CODE COVERAGE RESULTS          ║
╠═══════════════════════════════════════╣
║ Line Coverage:    100% (18/18)        ║
║ Branch Coverage:  100% (24/24)        ║
║ Complexity:       8                   ║
╚═══════════════════════════════════════╝

Copertura per Metodo

Metodo	Lines	Branches	Complexity
findEvenIndex()	100%	100%	8

Statistiche e Analisi

Statistiche Dettagliate

jqwik raccoglie automaticamente statistiche durante l'esecuzione:

Test INVALID

╔════════════════════════════════════╗
║     INVALID INPUT STATISTICS       ║
╠════════════════════════════════════╣
║ Tentativi:        1000             ║
║ Successi:         1000 (100%)      ║
║ Fallimenti:       0                ║
║ Dim. media liste: 3.2 elementi     ║
╚════════════════════════════════════╝

Distribuzione per Tipo:
├─ Liste vuote:        33.2%
├─ Solo positivi:      33.4%
└─ Solo negativi:      33.4%

Test FAIL (Solo Dispari)

╔════════════════════════════════════╗
║       FAIL STATISTICS              ║
╠════════════════════════════════════╣
║ Tentativi:        1000             ║
║ Successi:         1000 (100%)      ║
║ Fallimenti:       0                ║
║ Dim. media liste: 42.5 elementi    ║
╚════════════════════════════════════╝

Distribuzione Positivi/Negativi:
┌─────────────────────────────────┐
│ ████████████░░░░░░░░░░░░ 53.8%  │ Positivi
│ ░░░░░░░░░░░░████████████ 46.2%  │ Negativi
└─────────────────────────────────┘

Test PASS (Con Numeri Pari)

╔════════════════════════════════════╗
║       PASS STATISTICS              ║
╠════════════════════════════════════╣
║ Tentativi:        1000             ║
║ Successi:         1000 (100%)      ║
║ Fallimenti:       0                ║
║ Dim. media liste: 35.0 elementi    ║
╚════════════════════════════════════╝

Distribuzione Pari/Dispari:
┌─────────────────────────────────┐
│ ████████████████████████ 50.1%  │ Pari
│ ███████████████████████░ 49.9%  │ Dispari
└─────────────────────────────────┘

Esempi di Input Generati:
• [12, -45, 78, -23, 44, 91, -66, 33, 18, ...]
• [-88, 77, -44, 55, -22, 11, 66, -99, 44, ...]
• [3, -8, 15, -42, 27, -56, 31, 64, -19, ...]

Grafici Generati

I test producono automaticamente visualizzazioni:

1. Istogramma Positivi/Negativi (Test FAIL)
2. Grafico Combinato Pari/Dispari con frequenze (Test PASS)
3. Distribuzione Dimensioni Liste

Disponibili in: target/jqwik-reports/

🎯 Vantaggi Riscontrati

Property-Based Testing vs Traditional Testing

Aspetto	Testing Tradizionale	Property-Based Testing
Test Cases	Scritti manualmente (10-50)	Generati automaticamente (1000+)
Tempo scrittura	Alto (ore)	Basso (minuti)
Copertura	Casi previsti	Esplora casi imprevisti
Bug Detection	Dipende dall'esperienza	Trova edge cases nascosti
Manutenzione	Alta	Bassa
Confidence	Media	Alta

Caso Pratico

Con Testing Tradizionale avresti dovuto scrivere:

• ~10 test per input validi
• ~5 test per input non validi
• ~5 test per casi limite
• Totale: ~20 test scritti manualmente

Con Property-Based Testing hai scritto:

• 3 proprietà generali
• jqwik ha eseguito 3000+ test automaticamente
• Maggiore copertura con meno codice

---

🚀 Quick Start

Prerequisiti

Java JDK 17 o superiore
Maven 3.8+
IDE (consigliato: IntelliJ IDEA)

Installazione

# Clona il repository
git clone https://github.com/LauraCroce/TestMaster.git
cd TestMaster

Esecuzione Test

Homework 1: KebabCase

cd homework1

# Esegui tutti i test
mvn test

# Genera report di coverage (JaCoCo)
mvn jacoco:report
# Report → target/site/jacoco/index.html

# Esegui mutation testing (PITest)
mvn org.pitest:pitest-maven:mutationCoverage
# Report → target/pit-reports/index.html

# Esegui tutto insieme
mvn clean test jacoco:report org.pitest:pitest-maven:mutationCoverage

Homework 2: EvenIndex

cd homework2

# Esegui property-based tests
mvn test

# Genera report di coverage
mvn jacoco:report
# Report → target/site/jacoco/index.html

# Con statistiche dettagliate
mvn test -Djqwik.reporting=true

---

📂 Struttura del Progetto

TestMaster/
├── README.md                        # Questa documentazione
├── .gitignore                       # File da escludere
│
├── homework1/                       # Specification & Structural Testing
│   ├── src/
│   │   ├── main/java/homework1/
│   │   │   ├── KebabUtil.java       # Classe da testare
│   │   │   └── Main.java            # Esempio utilizzo
│   │   └── test/java/homework1/
│   │       ├── KebabUtilTest.java              # Test base
│   │       └── KebabUtilParameterizedTest.java # Test parametrizzati
│   ├── pom.xml                      # Configurazione Maven
│   └── target/
│       ├── site/jacoco/             # Report JaCoCo
│       └── pit-reports/             # Report PITest
│
├── homework2/                       # Property-Based Testing
│   ├── src/
│   │   ├── main/java/homework2/
│   │   │   └── EvenIndex.java       # Classe da testare
│   │   └── test/java/homework2/
│   │       ├── EvenIndexTest.java         # Property-based tests
│   │       └── EvenIndexTestCase.java     # Test tradizionali
│   ├── pom.xml
│   └── target/
│       ├── site/jacoco/
│       └── jqwik-reports/           # Report jqwik
│
└── docs/
    └── ITSS_Documentazione_2324.pdf # Relazione completa

---

📚 Documentazione

Documentazione Disponibile

• Relazione Tecnica Completa (PDF) - 44 pagine di analisi dettagliata
• Test Cases Excel - Documentazione test case con template
• JavaDoc - Documentazione del codice (generabile con mvn javadoc:javadoc)
• Coverage Reports - Report JaCoCo e PITest

Report Generati

JaCoCo Coverage (Homework 1 & 2)

• Posizione: target/site/jacoco/index.html
• Contenuto:
  • Line coverage per classe
  • Branch coverage
  • Complexity metrics
  • Codice sorgente annotato

PITest Mutation (Homework 1)

• Posizione: target/pit-reports/index.html
• Contenuto:
  • Mutation score
  • Mutazioni per mutator type
  • Codice mutato
  • Test che hanno ucciso le mutazioni

jqwik Statistics (Homework 2)

• Posizione: target/jqwik-reports/
• Contenuto:
  • Statistiche distribuzione dati
  • Grafici e istogrammi
  • Shrinking examples
  • Edge cases trovati

---

🧠 Apprendimenti Chiave

1. Testing Methodology

Specification-Based vs Structural Testing:

• Il testing black-box (specification-based) è fondamentale per verificare i requisiti
• Il testing white-box (structural) garantisce copertura del codice
• Entrambi sono necessari per un testing completo

Lesson Learned:

100% code coverage non garantisce assenza di bug. I boundary cases hanno rivelato bug che la coverage da sola non avrebbe trovato.

2. Mutation Testing Value

Prima di PITest:

• Test suite con 17 test
• 100% line e branch coverage
• Fiducia nella qualità: Alta

Dopo PITest:

• Mutation score: 100% (9/9 mutazioni uccise)
• Conferma: I test rilevano effettivamente errori
• Fiducia nella qualità: Molto Alta ✅

Lesson Learned:

Mutation testing è essenziale per validare la qualità dei test, non solo la quantità.

3. Property-Based Testing

Vantaggi Concreti:

• ✅ Trovato edge case imprevisto: lista con solo zeri
• ✅ Verificato comportamento su 3000+ combinazioni
• ✅ Ridotto tempo di scrittura del 80%
• ✅ Aumentata fiducia grazie alle statistiche

Quando usarlo:

• ✅ Logica complessa con molti casi possibili
• ✅ Algoritmi matematici
• ✅ Funzioni pure (stesso input → stesso output)
• ❌ UI testing
• ❌ I/O operations
• ❌ Comportamenti non deterministici

Lesson Learned:

Property-based testing non sostituisce i test tradizionali, ma li complementa efficacemente per una copertura più ampia.

4. Documentation Importance

Cosa abbiamo documentato:

• ✅ Ogni test case con input/output atteso
• ✅ Decisioni di design
• ✅ Bug trovati e fix applicati
• ✅ Metriche e risultati

Perché è importante:

• Facilita manutenzione futura
• Aiuta altri sviluppatori a capire le scelte
• Dimostra processo sistematico
• Essenziale per progetti accademici e professionali

5. Tools Matter

Tools utilizzati e loro valore:

Tool	Valore Aggiunto	Difficoltà Apprendimento
JUnit 5	Framework standard, ben documentato	Bassa
JaCoCo	Visualizzazione immediata coverage	Bassa
PITest	Valutazione qualità test	Media
jqwik	Automazione test massiva	Alta
Maven	Build automation standardizzata	Media

Lesson Learned:

Investire tempo nell'apprendimento dei tool giusti ripaga ampiamente nel lungo periodo.

---

🎓 Metodologia di Lavoro

Processo Seguito

1. 📖 Analisi Requisiti
   ↓
2. 🎯 Identificazione Partizioni & Boundary Cases
   ↓
3. ✍️  Scrittura Test Cases (Specification-Based)
   ↓
4. 💻 Implementazione Codice
   ↓
5. 🧪 Esecuzione Test & Debug
   ↓
6. 📊 Coverage Analysis (JaCoCo)
   ↓
7. 🦠 Mutation Testing (PITest)
   ↓
8. 🔄 Property-Based Testing (jqwik)
   ↓
9. 📝 Documentazione Risultati

Best Practices Applicate

✅ TDD (Test-Driven Development) - Test scritti prima del codice
✅ Continuous Testing - Test eseguiti ad ogni modifica
✅ Code Review - Revisione incrociata del codice
✅ Version Control - Git per tracciabilità modifiche
✅ Documentation First - Documentazione contestuale al codice
✅ Automated Reporting - Report automatici di qualità

---

🤝 Contributi

Questo è un progetto accademico completato. Non sono accettati contributi esterni, ma sentitevi liberi di:

• 🔀 Fork per scopi educativi
• ⭐ Star se trovate il progetto utile
• 📧 Contattarci per domande o chiarimenti

---

📄 Licenza

Questo progetto è stato sviluppato per scopi accademici presso l'Università degli Studi di Bari.

---

📞 Contatti

Per domande, chiarimenti o collaborazioni:

Laura Croce
📧 l.croce2@studenti.uniba.it
🔗 GitHub
💼 LinkedIn

---

⭐ Se questo progetto ti è stato utile, lascia una stella!

Made with ❤️ and ☕ by Team TestMaster

⬆️ Torna su