Testing Software: Specification vs Structural

Introduzione alla Dispensa ITSS

• La dispensa è un riassunto sull'integrazione e sui test dei sistemi software.
• L'autore è Tarulli Marrafia Alessia.

1 Software Testing

• Cos'è il Software Testing? È un insieme di attività per pianificare, preparare e valutare i prodotti software per verificare se soddisfano i requisiti, se sono mirati allo scopo desiderato e per trovare difetti nel codice.

• Errori, Bug e Failure: Gli errori umani possono creare bug (difetti nel codice), che a loro volta possono causare failure (fallimenti) quando il codice è in esecuzione. Un sintomo di failure è un incident.

• Test e Test Case: Il testing è l'esecuzione del software attraverso casi di test, con l'obiettivo di individuare bug o malfunzionamenti e dimostrare la corretta esecuzione del prodotto. Un test case specifica un insieme di input e i corrispondenti output attesi per un determinato comportamento.

1.3 Test Case

• Elementi essenziali di un Test Case: Un test case deve includere un identificatore, una descrizione dello scopo, le precondizioni, gli input, gli output attesi, e le postcondizioni, oltre allo storico dell'esecuzione.

1.4 Identificare i casi di test

• Dominio di input: Le possibili combinazioni di input per un sistema.
• Strategie per individuare casi di test:
  • Test funzionali (specification-based): basati sulle specifiche del prodotto. Sono "black-box", in quanto la struttura interna del prodotto è ignota ai test.
  • Test strutturali (code-based): studiano la struttura interna del codice. Sono anche detti "white-box".

1.4.1 Specification-based Testing

• Vantaggi: I test sono indipendenti dall'implementazione e possono essere sviluppati parallelamente a questa.
• Svantaggi: Non vengono testati tutti i possibili percorsi del codice.

1.4.2 Structural-based Testing (Code-Based)

• Approccio basato direttamente sull'implementazione del codice sorgente.
• White-box testing: Permette di testare tutti o quasi tutti i percorsi di esecuzione del programma.

1.5 Errori e Difetti

• Processo: Come un sistema crea qualcosa.
• Prodotto: Il risultato di un processo.
• Software Quality Assurance: Migliora i processi per ridurre gli errori e migliorare i prodotti (software).
• Testing: Si concentra in particolare sull'individuazione dei difetti in un prodotto (software).

1.6 Livelli di Testing (V-model)

• I livelli di testing riflettono i livelli di astrazione del modello a cascata.
• I livelli di testing comprendono: sistematico, d'integrazione e unit testing.

2 Specification-based Testing

• Requisiti: Descrivono cosa un software deve fare (quali sono gli ingressi e quali sono le uscite desiderate). Sono la base dell'approccio specification-based dei test.

2.2 Workflows per il Testing basato su Specifiche

• Comprendere i requisiti e gli output: Identificare cosa deve fare il programma e quali sono le uscite per ogni input.
• Input, output, e partizioni: Definire i possibili ingressi, output e partizioni di questi.
• Casi limite: Identificare i casi limite (valori estremi e situazioni speciali).
• Test Cases: Ideare dei casi di test.
• Automatizzazione: Automatizzare i casi di test, utilizzando uno strumento come JUnit

2.2.1 Comprendere i requisiti, gli input e le uscite

• Ognuno dei tre punti di suddivisione dei requisiti è fondamentale.

2.2.2 Esplorazione degli input possibili

• Una tecnica per aumentare la comprensione funzionale del programma.

2.2.3 Esplorare input e output, identificare le partizioni

• Scopo: individuare subset di input/output che forniscono completa certezza sulla correttezza funzionale del programma.

3 Testing strutturale e copertura del codice

• Passaggi per il testing strutturale:

  1. Applicare i passaggi di testing basati su specifiche.
  2. Studiare l'implementazione, cercando di capire come il codice gestisce le decisioni.
  3. Utilizzare uno strumento di copertura del codice per identificare le parti di codice non coperte dai test.
  4. Definire perché un pezzo di codice non è stato coperto.
  5. Creare un testcase per coprire il pezzo di codice mancante.
  6. Tornare al punto 3

• Criteri di copertura del codice:

  • Line coverage: Quanti righe di codice sono state eseguite.
  • Branch coverage: Quanti rami (condizioni) di codice sono stati eseguiti.
  • Condition/Decision coverage: Qualsiasi condizione logica (es. una condizione if) in cui sia il ramo vero (true) che quello falso (false) sono stati testati.
  • Path coverage: Tutti i percorsi possibili di esecuzione del programma sono coperti dai test.

3.3 Condizioni complesse e il criterio di copertura MC/DC

• Cosa fa: Identifica le combinazioni di condizioni che sono necessarie per coprire il codice al meglio.
• Vantaggio: Rende più complete le suite di test.

3.4 Gestire cicli e strutture simili

• Lo scopo è definire come i test devono coprire tutti gli stati di un ciclo e gestire i diversi percorsi di esecuzione.

4 Progettare contratti

• Design by contract: Metodologia per definire requisiti e comportamenti attesi in classi e metodi.
  • Precondizioni: Requisiti preliminari per il corretto funzionamento.
  • Postcondizioni: Risultati garantiti dopo l'esecuzione.
  • Invarianti: Condizioni che devono essere vere durante l'intero ciclo di vita dell'oggetto.

4.1 Perché progettare i contratti

• Ogni classe o metodo sappia cosa aspettarsi (pre-condizioni).
• Ogni metodo restituisca risultati corretti (post-condizioni).
• Lo stato interno degli oggetti rimanga consistente (invarianti).

4.2 Elementi fondamentali

• Pre-condizioni: Requisiti che devono essere soddisfatti prima dell'esecuzione.
• Post-condizioni: Condizioni che devono essere soddisfatte dopo l'esecuzione.
• Invarianti: Condizioni che devono essere mantenute validi durante tutto il ciclo di vita dell'oggetto.

4.3 Esempi pratici

• TaxCalculator: Calcolo tasse, pre-condizione valore maggiore di zero, post-condizione risultato non negativo.
• Basket: Rappresenta il carrello della spesa, con metodi per aggiungere e rimuovere prodotti, pre-condizioni e post-condizioni relative.

4.4 Assert e Controllo delle Condizioni

• Asserts sono test automatici, che, in caso di condizione non rispettata, interrompono l'esecuzione.

5 Test basati su proprietà

• Definizione: Verifica che un sistema soddisfi le caratteristiche generali previste, anziché i singoli casi d'uso.
• Vantaggi:
  • Copertura più ampia: copre un gran numero di casi d'uso o partizioni.
  • Riduzione della dipendenza da esempi: Il framework automatizza la generazione dei casi di test casualmente.

5.1 Differenza tra Example-Based e Property-Based Testing

• Example-Based Testing (EBT): Approccio tradizionale. I casi di test sono creati manualmente, basati sull'esperienza e sulla specificità del progetto.
• Property-Based Testing (PBT): Approccio moderno. Genera in automatico molti esempi di input per testare le proprietà del programma in esame.

5.3 Processo di PBT

• Definire le proprietà: Si identificano le proprietà generali del programma.
• Generazione degli input: Si genera un gran numero di input per testare le proprietà individuate.
• Esecuzione dei test: Il programma viene eseguito con gli input generati. Per ogni input, se una proprietà viene violata, il test fallisce.

6 Test Double e Mocks

• Generalità: Oggetti (o componenti) utilizzati per simulare il comportamento di componenti o dipendenze reali in un test, per isolare e rendere più veloci i test.

• Dummy Objects: Oggetti di riempimento, utilizzati per soddisfare i requisiti di parametri di metodi, senza alcuna implementazione.

• Fake Objects: Simulazione di oggetti reali, ma con implementazioni semplificate o alternative, spesso in modo che il framework di test non debba accedere a database esterni.

• Stubs: Restituiscono valori predefiniti o in base a criteri interni, con funzionalità più semplici di quelle reali.

• Mocks: Registrano chiamate e controlli, per valutare il comportamento effettivo del codice da testare in risposta ad un determinato input.

6.1 Tipi di Test Doubles

• Si descrivono i diversi tipi di test double, i casi in cui sono impiegati, i vantaggi e gli svantaggi di ogni implementazione

6.2 Framework Mocking (Mockito)

• Si descrive il framework Mockito, il cui scopo è facilitare la creazione e la gestione di mocks.

6.3 Stubbing delle Dipendenze

• Descrivere cosa è lo stubbing e perché è utile per il testing.

6.5 Best Practices per l'uso dei Test Double

• Si forniscono le best practices per l'uso dei test double, per ottimizzare le strategie adottate per il testing.

7 Testing Statico

• Definizione: Un approccio per individuare anomalie nel codice software senza eseguire il codice effettivamente.
• Si descrivono diverse tecniche di questo tipo di testing.

7.1 Analisi Statica

• Descrizione, utilizzo degli strumenti, e i difetti che può rilevare

7.2 Tipi di revisione del codice

• Ispezione del codice (Code Inspection): Revisione formale condotta da un gruppo di esperti per identificare difetti.
• Revisione del codice (Code Walkthrough): Presentazione informale di chi ha scritto il codice, per raccogliere feedback.
• Verifica a scrivania (Desk Checking): il programmatore rivede il codice da solo per individuare possibili errori.
• Valutazione tra pari (Peer Review): Valutazione del codice, del lavoro o della competenza di uno sviluppatore da parte dei suoi colleghi basata su criteri di qualità, efficienza e conformità agli standard.

7.3 Revisione del Codice: Ispezione e Walkthrough

• Si descrivono i passaggi per le revisioni del codice, ispezione e walkthrough.

7.4 Code Inspection

• Si descrive il metodo di code inspection e descrive le persone coinvolte.

7.5 Desk Checking

• Un tipo di revisione del codice, eseguito da una persona diversa da chi ha scritto il codice.

7.6 Peer Rating

• Valutazione che si concentra sulla qualità complessiva del programma (manutenibilità, estensibilità, usabilità).

7.7 Auditing

• Un esame indipendente per valutare la conformità a standard.

7.8 Pair Programming

• Descrizione dei ruoli, le motivazioni, i vantaggi, e il ruolo nel metodo XP.

7.9 GitHub Copilot

• Rappresenta un'implementazione di "pair programming" con intelligenza artificiale.

8 Progettazione per Testabilità

• Separazione del codice: Separare il codice di dominio dal codice di infrastruttura.
• Controllabilità e osservabilità.
• Modifica del codice di produzione: A volte il test si complica se i test non sono progettati bene, quindi bisogna modificare il codice di produzione per facilitare il testing.

8.3 Controllabilità e Osservabilità

• Controllabilità: Facilità con cui iniettare valori arbitrari nel codice testato.
• Osservabilità: Facilità con cui visualizzare i risultati o l'output.

8.4 Principio di Inversione delle Dipendenze

• Moduli di alto livello non dovrebbero dipendere dai moduli di basso livello. Entrambe le parti dovrebbero dipendere da astrazioni o interfacce.
• Vantaggi: Riduce la dipendenza da dettagli, migliorando la testata.

8.5 Coesione

• Coesione: Un modulo, una classe o un metodo dovrebbe avere una sola responsabilità.
• Problema: Classi non coese hanno test più ampi.
• Soluzione: Rifattorizzazione delle classi.

8.6 Conclusione

• Separazione del codice: Separare il codice di infrastruttura dal codice di dominio.
• Controllabilità e osservabilità: Rendi il codice controllabile e osservabile.
• Modifica al codice di produzione (se necessario): A volte bisogna modificare il codice di produzione per rendere il testing più facile.

9 Test di Integrazione & Sistema

• Definizione: Esercita gruppi di componenti correlati e l'interazione con servizi esterni (es. Database).
• Test di Sistema: Verifica l'intero sistema end-to-end, simulando l'interazione dell'utente.
• Test d'integrazione: I Test d'integrazione verificano l'interazione tra componenti di un sistema per testare il processo d'integrazione tra gli applicativi.
• Tecniche di testing SQL: Gestione di query SQL che non selezionano alcuna riga, query che selezionano righe identiche, query con sottoquery, gestione di predicati LIKE, date e stringhe.
• Verifica dei vincoli del database: Utilizzare JUnit per la verifica dei vincoli del database.
• Implementazione JDBC di InvoiceDao: Si mostra un esempio, come creare una classe base per gestire le connessioni al database.
• Best Practices per i Test di Integrazione: Si forniscono le best practices: creare una classe base, ridurre i dati, considerare evolzione dello schema.

10 Test di Sistema

• Introduzione ai test di sistema.
• Esempio applicativo web.
• Flusso di lavoro applicativo web.
• Strumenti (Selenium).
• Test dei percorsi utente.
• Page Objects (POs).
• Esempio di test di sistema.

11 TDD (Test-Driven Development)

• È una metodologia di sviluppo software dove si scrivono i test prima dell'implementazione del codice.
• Vantaggi: Controllare il ritmo, feedback veloci, codice testabile, facile da modificare, migliore capacità di riflessione sui requisiti.
• Casi limite, stringhe vuote e nulle.
• Passaggi del TDD:
  1. Scrivere un test che fallirà.
  2. Implementare il codice che fa passare il test.
  3. Rifattorizzare il codice per migliori pratiche, sicurezza e eleganza.

12 Integrazione Tra Sistemi Software

• Motivazioni per l'integrazione di sistemi software (es. evoluzione sistemi, tecnologie obsolete).
• Tecniche e strumenti EAI (Enterprise Application Integration).