Issues Risolti

Issue #12: Logout in /editorAllenamento

Descrizione del problema: Il pulsante "Logout" nella pagina /editorAllenamento non permetteva il corretto indirizzamento.
Soluzione adottata: Durante l'analisi del codice, è stato identificato un bug nella logica di gestione del logout. Questo è stato corretto rendendolo un pulsante “Indietro” per garantire che, alla pressione del pulsante l'utente sia reindirizzato correttamente alla pagina main, nella quale poi potrà eventualmente eseguire il logout.

Issue #17: Mantenimento della sessione di gioco

Descrizione del problema: Il gioco integrava un editor in cui gli utenti potevano scrivere e modificare il contenuto, ma in caso di refresh della pagina o di navigazione verso un'altra sezione, le modifiche venivano perse.
Soluzione adottata: È stato implementato un sistema di salvataggio temporaneo dei progressi, che utilizza local storage per preservare i dati durante la sessione. Questo ha consentito agli utenti di riprendere il lavoro esattamente da dove avevano lasciato, anche dopo aver aggiornato la pagina o essere tornati all'editor.

Issue #20: Verifica dei requisiti di concorrenza

Descrizione del problema: La piattaforma richiedeva la capacità di gestire accessi concorrenti (Es: la compilazione) da parte di più utenti.
Soluzione adottata: È stata realizzata una campagna di testing utilizzando JMeter per simulare l'accesso contemporaneo di più utenti. Grazie a questi test, è stato possibile confermare che la gestione della concorrenza è stata implementata correttamente e che il sistema può sostenere efficacemente più utenti in simultanea senza compromettere la stabilità.

Issue #36: Pulsante "Submit" in modalità Partita Singola

Descrizione del problema: Al termine di una partita singola, il pulsante "Submit" rimaneva attivo, permettendo all'utente di inviare ulteriori dati anche dopo la conclusione della partita, causando inconsistenze nei risultati.
Soluzione adottata: Il problema era dovuto a un bug nel codice che gestiva l'abilitazione del pulsante. Dopo aver corretto il bug, il pulsante "Submit" viene ora disabilitato automaticamente alla fine della partita, garantendo un comportamento corretto.

Issue #37: Pulsante "Logout" invisibile con colori chiari

Descrizione del problema: In alcune sezioni con colori chiari, il pulsante "Logout" / “Indietro” risultava invisibile a causa della mancanza di contrasto.
Soluzione adottata: Anche in questo caso si trattava di una svista nel codice relativo allo stile del pulsante, che è stato risolto. Il CSS è stato aggiornato per garantire un contrasto adeguato in tutte le pagine, così da mantenere sempre visibile il pulsante "Logout" / “Indietro” indipendentemente dal tema o dai colori di sfondo.

Issue #41: Problemi di compilazione dei test in modalità Partita Singola

Descrizione del problema: Dopo aver giocato con una determinata classe, i test di compilazione fallivano quando l'utente cambiava classe.
Soluzione adottata: Il problema derivava da una gestione non ottimale della logica delle partite. È stato introdotto un meccanismo per rilevare e gestire le partite già iniziate, permettendo la ripresa delle partite non completate oppure la possibilità di creare una nuova partita con una nuova classe. Questo ha risolto il problema di compilazione e migliorato l’esperienza utente.

Issue #42: Esecuzione dei test in modalità Allenamento

Descrizione del problema: Un bug nella logica di gestione delle partite ha impedito il corretto svolgimento dei test. Questo problema ha innescato una serie di bug a catena.
Soluzione adottata: Il bug è stato risolto nel codice, assicurando che i test possano ora essere eseguiti in modo corretto anche nella modalità Allenamento e risolvendo di conseguenza una insieme di errori.

Bugfixes Vari

Stato del tasto per abbassare/alzare la console nell'editor

Descrizione del problema: Nell'editor, il tasto per abbassare la console non si aggiornava correttamente se l’utente alzava/abbassava la console manualmente. In particolare, la combinazione della duplice funzione di gestione della finestra (tramite pulsante o manuale) generava un problema in cui la freccia indicava sempre la direzione sbagliata.
Soluzione adottata: Abbiamo aggiunto un controllo sullo stato dell'icona per verificare se la console fosse aperta (altezza > 0) o chiusa (altezza = 0), aggiornando di conseguenza l’icona. Ora la freccia riflette correttamente lo stato della console, migliorando la coerenza dell'interfaccia.

Doppia scroll bar negli editor

Descrizione del problema: Entrambi gli editor visualizzavano una doppia scroll bar, causando problemi di navigabilità e una visualizzazione disordinata.
Soluzione adottata: La causa era legata a una configurazione non ottimale di CodeMirror, il componente di editing utilizzato. Dopo aver identificato il problema, abbiamo modificato le impostazioni per rimuovere la scroll bar superflua, ottenendo così un'interfaccia più pulita e user-friendly.

Perdita dei dati in modalità Sfida durante il cambio lingua o il refresh

Descrizione del problema: In modalità Sfida, se l'utente effettuava un submit e successivamente cambiava la lingua o aggiornava la pagina durante lo stato di caricamento/invio dei dati, i progressi venivano persi, generando inconsistenza o perdita di dati.
Soluzione adottata: È stato implementato un sistema di avviso tramite modal che si attiva quando l'utente tenta di cambiare lingua o aggiornare la pagina in seguito a un submit (o ad una coverage). Questo avviso permette di evitare la perdita accidentale dei progressi e consente all’utente di evitare di causare un danno.

Inizio partita senza aver selezionato tutti e tre i campi

Descrizione del problema: In gamemode, era possibile iniziare una partita senza aver selezionato tutti e tre i parametri necessari, generando inconsistenza.
Soluzione adottata: Reso il pulsante “Inizia partita” non cliccabile senza aver prima selezionato classe, difficoltà e tipo di robot

Tasti play nella home fuoriescono dai confini

Descrizione del problema: I tasti play non si adattavano correttamente alla grandezza della finestra del browser, causando dei bug nella visualizzazione della pagina
Soluzione: Abbiamo modificato l’html per risolvere il problema

Funzione di highlight della Coverage migliorata

Descrizione del problema: La funzione di highlight per la coverage in editor rendeva talvolta illeggibile le righe e non facevano comprendere bene la coverage raggiunta, poiché basata sul sottolineare il testo e quindi le combinazioni di colore non erano ottimali.
Soluzione: abbiamo modificato la funzione di highlight per renderla più simile all'approccio di VSCode , rendendola più leggibile tramite un recolor del gutter dell'editor in base alla coverage di quella riga.

Testing del Codice e Garanzia di Coverage

Nell’ambito del nostro progetto, abbiamo implementato un'ampia serie di test per garantire un’ampia copertura completa del codice, assicurando che ogni funzionalità sia adeguatamente verificata e pronta per un utilizzo.

Classi di Test Implementate per T5 - Interfaces All'interno del package T5, abbiamo sviluppato nuove classi di test per coprire i package “Interfaces” e “Components”.

Test per il BaseService, abbiamo introdotto un test di unità sulla classe che permette di definire un servizio e valutare l'esecuzione delle azioni.
Test per i servizi T1, T23, T4 per valutarne la corretta esecuzione delle proprie azioni e la comunicazione.
Test per il serviceManager, per valutare che istanzi e gestisca le richieste nel modo giusto

Il package Interfaces risulta avere una COV pari a 93%.

Classi di Test Implementate per T5 - Components

Uno StubServiceManager per imitare il comportamento di quest'ultimo e poter testare in termini di unità i componenti
Test per AuthComponent, GenericObjectComponent e VariableValidationLogicComponent per valutarne il corretto funzionamento.
ServiceLogicComponent e ServiceObjectComponent sono stati testati usando lo stub
PageBuilder è stato testato per valutare se gestisce correttamente i componenti e l'emissioni di codice d'errore.

Il package Componentsrisulta avere una COV pari a 73%, poiché manca una classe, che termineremo a breve.

Classi di Test Implementate per T7 Per quanto riguarda il task T7 abbiamo introdotto 3 classi di test:

AppControllerTest sono test mirati a testare l'interfaccia dell'API e sono realizzati in maniera parametrizzata e sfruttano dei file esterni da cui prendere le sorgenti di compilazione, vi sono sia test sulla compilazione, sia sulla formattazione della classe di test.
AppController_concurrencyTest sono test mirati a valutare la concorrenza dell'API, vi sono 4 tipi di test, 3 basati su un pool di thread e l'ultimo si basa sul vedere se c'è un timeout.
CompilationServiceTest sono test mirati a valutare la logica implementata quando ci si trova con un sistema malformato.

Internazionalizzazione della Web App

Abbiamo integrato la funzionalità di internazionalizzazione per gestire il contenuto testuale dell'applicazione in italiano, inglese e spagnolo. Ora, tutte le pagine accessibili dall'utente supportano la multilingua, migliorando l'accessibilità e l’esperienza per utenti di diverse lingue. Di seguito i passaggi seguiti per implementare questa funzionalità, seguendo le linee guida di Spring Boot per l'internazionalizzazione:

Passaggi per Implementare l'Internazionalizzazione

Creazione dei File di Risorse

Sono stati creati file di risorse per ogni lingua supportata all’interno della cartella src/main/resources. Ogni file mappa le stringhe testuali dell'applicazione.
I file di risorse seguono la convenzione messages_xx.properties, con xx come codice della lingua (es. messages_it.properties per l’italiano, messages_en.properties per l’inglese, e messages_es.properties per lo spagnolo).

Configurazione della Lingua Predefinita

L’italiano è stato impostato come lingua predefinita dell’applicazione. Se l'utente non ha specificato una preferenza di lingua, l'app utilizza automaticamente l’italiano.

Impostazione del CookieLocaleResolver

Abbiamo utilizzato un CookieLocaleResolver per gestire la selezione della lingua, permettendo di salvare la preferenza linguistica in un cookie dalla durata di una settimana. Questo consente all'applicazione di mantenere la scelta della lingua dell'utente anche tra diverse sessioni e dopo la chiusura del browser.

Creazione di un Interceptor per il Cambio di Lingua

È stato configurato un LocaleChangeInterceptor per ascoltare le modifiche di lingua tramite un parametro specifico (lang). Questo permette agli utenti di cambiare lingua dinamicamente senza dover riavviare la sessione.
Utilizzando un selettore di lingua presente in ogni pagina accessibile nella navbar, l'utente può cambiare lingua e l’intercettore aggiorna il contesto di visualizzazione.

Integrazione del Multilingua nelle Pagine Web

I messaggi testuali presenti nel frontend dell'applicazione sono stati collegati ai rispettivi file di risorse. Abbiamo modificato le pagine HTML e i template per fare riferimento ai messaggi localizzati tramite parole chiave, garantendo che il contenuto sia visualizzato nella lingua selezionata.

Testing del Multilingua

Dopo l'implementazione, sono stati eseguiti test per verificare che ogni pagina reagisse correttamente al cambio di lingua, simulando scenari diversi di cambio lingua per assicurare che la preferenza venisse mantenuta tra le sessioni.

Testing-Game-SAD-2023 / A13

Introduzione Struttura di Testing per T5 e T7 ed Bug fix all'editor. #45

Issues Risolti

Bugfixes Vari

Testing del Codice e Garanzia di Coverage

Internazionalizzazione della Web App