Università degli Studi di Padova - SIAGAS
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Università degli Studi di Padova
Dipartimento di Matematica "Tullio Levi-Civita"
Corso di Laurea in Informatica
Progettazione e sviluppo di una test suite
per un applicativo Android
Tesi di laurea triennale
Relatore
Prof.Gilberto Filè
Laureando
Lorenzo Menegon
Anno Accademico 2017-2018
Lorenzo Menegon: Progettazione e sviluppo di una test suite per un applicativo Android, Tesi di laurea triennale, c Dicembre 2018.
Design and programming are human activities; forget that and all is lost.
— Bjarne Stroustrup
Sommario
Il presente documento descrive il lavoro svolto durante il periodo di stage dal laureando
Lorenzo Menegon presso l’azienda Tradenet Services S.r.l di Schio (VI). Lo stage è
stato svolto tra settembre e novembre del 2018, ed ha avuto una durata complessiva di
300 ore.
L’obiettivo principale proposto dall’azienda è stata la definizione e la scrittura di test
di unità relativi alla versione Android di Zotsell, applicazione di punta dell’azienda. In
particolare è stato chiesto di definire una suite di testing che permettesse l’identificazione
in maniera automatica dei possibili problemi presenti all’interno dell’applicazione stessa,
per favorire poi una risoluzione di essi.
Il documento è diviso in quattro capitoli. Il primo capitolo presenta il contesto
aziendale di lavoro, includendo cenni alla storia e al way of working dell’azienda stessa.
Il secondo capitolo invece si pone l’obiettivo di spiegare come il progetto si renda utile
all’interno dell’azienda per l’attuale team di sviluppo. Il terzo capitolo è incentrato
sullo svolgimento dello stage descrivendo le principali problematiche incontrate, la loro
risoluzione, un’analisi in dettaglio sugli obiettivi espressi nel piano di lavoro da parte
dell’azienda e le scelte intraprese a livello di team. Il quarto capitolo presenta infine
un giudizio sullo svolgimento dello stage rispetto ai requisiti obbligatori, desiderabili e
facoltativi proposti dall’azienda, e alle conoscenze acquisite dallo studente.
v
Ringraziamenti
Innanzitutto vorrei esprimere la mia gratitudine al Prof.Gilberto Filè, relatore della
mia tesi, per l’aiuto e il sostegno fornitomi durante la stesura del lavoro.
Desidero ringraziare con affetto i miei genitori per il sostegno, il grande aiuto e per
essermi stati vicini in ogni momento durante gli anni di studio.
Vorrei infine ringraziare tutti gli amici che mi sono stati a fianco durante questi anni
di studio. Oltre a loro, tengo a ringraziare anche tutti gli altri che mi hanno aiutato
ad arrivare dove sono.
Padova, dicembre 2018 Lorenzo Menegon
vii
Indice
1 Il contesto aziendale 1
1.1 Il profilo aziendale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Prodotti offerti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Tecnologie utilizzate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.1 Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.2 Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.3 Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Processi aziendali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1 Metodologia Adaptive Software Development . . . . . . . . . . 5
1.4.2 Strumenti a supporto dei processi . . . . . . . . . . . . . . . . . 6
1.5 Rapporto con la clientela e propensione all’innovazione . . . . . . . . . 9
2 Lo stage nella strategia aziendale 11
2.1 Vantaggi aziendali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Presentazione del progetto . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Analisi dell’applicazione . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Analisi dell’architettura . . . . . . . . . . . . . . . . . . . . . . 13
2.2.3 Individuazione e codifica dei test . . . . . . . . . . . . . . . . . 14
2.2.4 Progettazione di un sistema di CI/CD . . . . . . . . . . . . . . 14
2.3 Aspettative aziendali . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Vincoli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.1 Vincoli metodologici . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.2 Vincoli temporali . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.3 Vincoli tecnologici . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5 Aspettative personali . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Resoconto dello stage 19
3.1 Pianificazione del progetto . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Analisi dell’applicazione in dettaglio . . . . . . . . . . . . . . . . . . . 19
3.2.1 Apprendimento delle tecnologie e dei framework utilizzati . . . 19
3.2.2 Familiarizzazione con la struttura del codice operativo . . . . . 20
3.2.3 Identificazione dei casi d’uso di maggiore importanza . . . . . . 20
3.2.4 Sul concetto di Inversione del Controllo . . . . . . . . . . . . . 21
3.3 Definizione dei test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.1 Definizione dei test di Interfaccia Grafica . . . . . . . . . . . . 21
3.3.2 Definizione dei test di unità . . . . . . . . . . . . . . . . . . . . 22
3.3.3 Anticipo imprevisto sulla tabella oraria . . . . . . . . . . . . . 24
3.4 Codifica dei test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
ixx INDICE
3.4.1 Premessa: il modulo di Login . . . . . . . . . . . . . . . . . . . 25
3.4.2 Tecnologie utilizzate . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.3 Codifica dei test d’interfaccia . . . . . . . . . . . . . . . . . . . 25
3.4.4 Codifica dei test di unità . . . . . . . . . . . . . . . . . . . . . 27
3.5 Realizzazione del sistema di Continuous Integration e Continuous Delivery 30
3.5.1 Continuous Integration . . . . . . . . . . . . . . . . . . . . . . 30
3.5.2 Continuous Delivery . . . . . . . . . . . . . . . . . . . . . . . . 31
4 Valutazione retrospettiva 33
4.1 Analisi dei risultati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.1 Soddisfacimento dei degli obiettivi . . . . . . . . . . . . . . . . 33
4.1.2 Problematiche incontrate . . . . . . . . . . . . . . . . . . . . . 33
4.2 Bilancio formativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.1 Conoscenza approfondita di Kotlin . . . . . . . . . . . . . . . . 34
4.2.2 Lavoro individuale e di gruppo . . . . . . . . . . . . . . . . . . 34
4.2.3 Piattaforme di versionamento e amministrazione di progetto . . 35
4.2.4 Problem solving . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3 Valutazione personale . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Glossary 37
Bibliografia 41Elenco delle figure
1.1 Schema di interazione tra Forza6 e i gestionali supportati. . . . . . . . 1
1.2 Screenshot della prima versione di Forza6 per iPad. . . . . . . . . . . . 2
1.3 Logo di ZotSell (http://zotsell.it/) . . . . . . . . . . . . . . . . . 2
1.4 Schema di interazione tra ZotSell e i server dei clienti. . . . . . . . . . 3
1.5 Riassunto del modello Adaptive software development, elaborato da
Pressman (2001) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6 Visualizzazione di un task all’interno del GTD aziendale. . . . . . . . . 7
1.7 Logo di GitLab (https://about.gitlab.com/) . . . . . . . . . . . . . 8
1.8 Operazioni di branch e merge . . . . . . . . . . . . . . . . . . . . . . . 8
2.1 Rappresentazione grafica della Clean Architecture. . . . . . . . . . . . 13
2.2 Principi base di un sistema di Continuous Integration e Continuous
Delivery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Integrazione di una suite di test con un sistema di CI/CD . . . . . . . 15
2.4 Diagramma di Gantt dello stage. . . . . . . . . . . . . . . . . . . . . . 17
3.1 Schermata contenente gli usecase riguardanti il modulo di login. . . . . 21
3.2 Tabella contenente alcuni test di interfaccia relativa al modulo ordini. 22
3.3 Schema generale del funzionamento di Dagger. . . . . . . . . . . . . . 24
3.4 Corpo della funzione InjectActivityWithFragment. . . . . . . . . . . . . 26
3.5 Implementazione di un test per recoverButton. . . . . . . . . . . . . . 26
3.6 Implementazione della funzione rotateDevice. . . . . . . . . . . . . . . 27
3.7 Implementazione del test di recoverPassword. . . . . . . . . . . . . . . 28
3.8 Implementazione della classe ConvertRegisterResponseUseCase. . . . . 30
3.9 Prova riguardante il funzionamento della Build e dei Test attraverso la
pipeline. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.10 Rappresentazione del sistema di Continuous Integration e Continuous
Delivery attraverso la piattaforma Gitlab. . . . . . . . . . . . . . . . . 32
xixii ELENCO DELLE TABELLE
Elenco delle tabelle
2.1 Obiettivi dello stage fissati da Tradenet. . . . . . . . . . . . . . . . . . 16Capitolo 1
Il contesto aziendale
1.1 Il profilo aziendale
Tradenet Services S.r.l nasce nel 1994 come web agency, unendo conoscenze trasversali
all’informatica e al marketing con lo scopo di sviluppare siti web progettati e realizzati
ad esigenza del cliente. Nel 1998 l’azienda decide di intraprendere un cambio di rotta
conseguente ad un’ampia diffusione dei Content Management System, sviluppando
la suite Forza6, un set completo di strumenti in grado di integrare le funzionalità
di Customer Relationship Management, Content Management System e store B2B,
disponibile in una prima versione esclusivamente online. Col susseguirsi del tempo
viene raggiunta una versione in grado di interagire con differenti sistemi di gestione
dati, a partire da SAP fino ai sistemi più recenti, creando per essi connettori appositi
atti a scambiare dati nella modalità di trasmissione migliore.
Figura 1.1: Schema di interazione tra Forza6 e i gestionali supportati.
Nel 2007, con la nascita dei dispositivi mobile di Apple, l’azienda decide subito di
mettersi in gioco . A seguito dell’uscita della prima generazione di Iphone, l’azienda
12 CAPITOLO 1. IL CONTESTO AZIENDALE
sviluppa e rilascia la prima versione iOS di Forza6 che permette il suo utilizzo anche
offline. Questa caratteristica diventerà una sorta di marchio di fabbrica della Tradenet.
Nel 2010, inoltre, a seguito dell’uscita del primo modello di iPad, viene creata una
versione di Forza6 anche per questo dispositivo, che diventerà lo strumento principale
per utilizzare la suite.
Figura 1.2: Screenshot della prima versione di Forza6 per iPad.
1.2 Prodotti offerti
Dopo lo sviluppo di Forza6 e il successo di tale applicazione, l’azienda decise di iniziare
lo sviluppo di ZotSell, che ancora oggi rimane il prodotto di punta dell’azienda.
Figura 1.3: Logo di ZotSell (http://zotsell.it/)
ZotSell è una piattaforma pensata per le aziende che permette di operare su tre
canali di vendita separati: vendite dirette (tramite agenti), vendite indirette (B2B) e
vendite automatiche ai clienti (Electronic Data Interchange).
La sua qualità principale consiste nel fatto di essere una app ordini completamete
parametrica. Questa caratteristica esclude la necessità di scrivere codice per adattare
qualsiasi esigenza di business del settore verticale. Essa è infatti in grado di rispondere
a diverse impostazioni che vengono immesse da server, riuscendo così a soddisfare un
gran numero di tipologie di clienti diversi. In totale essa comprende oltre 130 funzioni
e la possibilità di integrazione con 120 fonti Enterprise Resource Planning.1.3. TECNOLOGIE UTILIZZATE 3
Figura 1.4: Schema di interazione tra ZotSell e i server dei clienti.
1.3 Tecnologie utilizzate
Le tecnologie utilizzate dall’azienda per la realizzazione di Zotsell si possono raggruppare
nelle tre aree di maggiore interesse di sviluppo, ossia quella mobile, quella frontend e
quella backend.
1.3.1 Mobile
Tutti i prodotti aziendali sono disponibili sia su piattaforma Android che iOS. Le
tecnologie utilizzate variano in base al sistema operativo del rispettivo prodotto.
Android
Per lo sviluppo di applicazioni Android l’azienda ha deciso di utilizzare i seguenti
linguaggi di programmazione:
∗ Java: è un linguaggio di programmazione ad alto livello, orientato agli oggetti
e a tipizzazione statica, specificamente progettato per essere il più possibile
indipendente dalla piattaforma di esecuzione. Esso è stato scelto in quanto
risorsa molto utilizzata dagli sviluppatori dell’azienda che hanno potuto fin da
subito creare una struttura solida in un ambiente conosciuto.
∗ Kotlin: Kotlin è un nuovo linguaggio di programmazione general purpose,
multi-paradigma, open source in grado di girare su JVM, donando flessibilità
e funzionalità in continuo aggiornamento al codice stesso. Essendo Kotlin una
tecnologia attualmente in via di sviuluppo, tutti i programmatori interni all’a-
zienda hanno ricevuto un’adeguata formazione comprensiva di lezioni frontali,
documentazione, e materiale per esercitarsi al fine di comprenderne al meglio le
dinamiche e le funzioni principali.4 CAPITOLO 1. IL CONTESTO AZIENDALE
iOS
Per lo sviluppo di applicazioni iOS l’azienda ha deciso di utilizzare il linguaggio Swift, al
fine di produrre del codice facilmente manutenibile, oltre che a permettere di compilare
la versione anche per sistema operativo Mac.
1.3.2 Frontend
Tradenet, essendo stata una delle aziende precursori in Italia nel campo dello sviluppo
web ha maturato una profonda conoscenza di tecnologie per la realizzazione dei propri
prodotti.
Per quanto riguarda la parte front-end sono state utilizzate le seguenti tecnologie:
∗ Yii: Framework scritto in PHP per la creazioni di siti web mediante l’utilizzo
del Design Pattern Model View Controller.
∗ Yii 2: Diretta evoluzione di Yii.
∗ React-Native: Framework creato e mantenuto da Facebook per lo sviluppo
di UI dinamiche e complesse mantenendo una struttura semplice ed intuitiva
da utilizzare. Questa tecnologia è stata scelta per produrre un applicativo che
potesse essere portato in seguito su sistemi operativi desktop.
1.3.3 Backend
Per quanto riguarda la parte di backend invece il prodotto è stato sviluppato comple-
tamente con le seguenti tecnologie:
∗ PHP: è un linguaggio di scripting interpretato, originariamente concepito per la
programmazione di pagine web dinamiche. Esso è stato utilizzato principalmente
per la solida conoscenza acquisita in precedenza dagli sviluppatori.
∗ Java: è un linguaggio di programmazione ad alto livello, orientato agli oggetti
e a tipizzazione statica, specificamente progettato per essere il più possibile
indipendente dalla piattaforma di esecuzione. Esso è stato scelto per aumentare
le performance in alcune fasi particolari, come per esempio quella di elaborazione
dei dati. Per questa fase è stato utilizzato il framework Talend, per una migliore
estrazione di dati attraverso operazioni concorrenti. Esso è fortemente utilizzato
quindi nella porzione di architettura che comunica con il server del cliente, e
nella parte di elaborazione e gestione dei dati.1.4. PROCESSI AZIENDALI 5
1.4 Processi aziendali
1.4.1 Metodologia Adaptive Software Development
Per una scelta strategica, l’azienda si ritrova quotidianamente a dover sviluppare
soluzioni dove è richiesta una forte personalizzazione del prodotto in base alle specifiche
richieste del cliente. E’ quindi necessaria una costante interazione tra l’azienda e il
cliente per capire esattamente quali siano le richieste da soddisfare e come fornire un
prodotto di qualità. Il progetto necessita di una buona dose di flessibilità per via del
rapido cambimento dei requisiti, ma anche di essere in grado di fornire una stabilità
architetturale ben definita.
Per fare ciò, Tradenet necessita di un modello di sviluppo efficace in grado di agire
attivamente e rapidamente in base al confronto diretto con i clienti. La metodologia
scelta è la Adaptive Software Development.
Il metodo agile adottato da Tradenet consiste in uno sviluppo incrementale dei prodotti
che coinvolga il più possibile il cliente in modo da avere continui feedback riguardo il
cambiamento dei requisiti. Questa metodologia permette di creare e rendere disponibili
funzionalità utilizzabili dal cliente in tempi molto più rapidi rispetto ad altre metodo-
logie di lavoro. Ad ogni incremento aumenta quindi la convergenza del prodotto verso
le effettive esigenze del cliente.
Figura 1.5: Riassunto del modello Adaptive software development, elaborato da Pressman
(2001)
Questo metodo viene seguito dall’azienda e si fonda sui seguenti principi base:
∗ sviluppare qualcosa di utile;
∗ coltivare la fiducia degli stakeholders;
∗ costituire gruppi di lavoro competenti e collaborativi;6 CAPITOLO 1. IL CONTESTO AZIENDALE
∗ far sì che il team abbia la possibilità e sia in grado di prendere decisioni;
∗ consegnare spesso nuove versioni all’aggiunta di nuove funzionalità;
∗ incoraggiare l’adattabilità;
∗ cercare di ottenere l’eccellenza tecnica.
Il ciclo di vita dell’Adaptive Software Development si articola nelle seguenti fasi:
∗ prevedere (definire una vision del prodotto finale, assegnare compiti e ruoli,
scegliere come il gruppo di lavoro lavorerà insieme);
∗ ipotizzare (sviluppare una versione basata solo sulle caratteristiche, decidere delle
milestones ed un interation plan);
∗ esaminare (cioè consegnare spesso versioni con nuove caratteristiche testate, e
che il cliente testerà anche meglio con l’utilizzo);
∗ adattare (verificare i risultati delle versioni consegnate, ricontrollare l’ambiente
reale di utilizzo, testare così le prestazioni del gruppo di lavoro; adattare e
riadattare se necessario);
∗ chiudere (concludere il progetto, affrontare gli ultimi dettagli in sospeso e
festeggiare).
Settimanalmente vengono effettuate inoltre delle sessioni di brainstorming tra
gli sviluppatori ed i responsabili dei clienti per pensare a strategie efficienti al fine
di risolvere i problemi incontrati. In questi momenti, dedicati principalmente alla
condivisione di idee e pareri personali, è importante essere esaustivi per sanare ogni
dubbio. L’attività di brainstorming è praticata principalmente nella prima parte di
sviluppo di un progetto, andando ad essere eseguita sempre con minor frequenza.
1.4.2 Strumenti a supporto dei processi
Gestione di progetto
Come strumento di gestione di progetto, Tradenet utilizza principalmente la piattaforma
GitLab, insieme ad un software sviluppato internamente all’azienda che contenente
funzionalità per tutto il personale interno, chiamato Getting Things Done (GTD).
GTD Questo strumento permette a chiunque sia registrato al sistema di assegnare
dei task ad altri membri del sistema, che vengono informati tramite notifiche via
mail. Una volta aperto un task, la lista degli utenti che avranno accesso a quel to do,
potranno iniziare una discussione tramite l’inserimento di messaggi e risposte nella
sezione apposita della pagina di visualizzazione del task. Per ogni task creato si possono
specificare i seguenti dettagli:
∗ il ricevente del task;
∗ inviare mail di notifica;
∗ aggiungere la priorità di urgente, mettendolo in evidenza fino all’effettiva risolu-
zione;
∗ lo stato del task (Nuovo, Da fare, Fatto, Archiviato, In attesa, In valutazione);1.4. PROCESSI AZIENDALI 7
∗ la tipologia di attività (Controllo urgente, Assistenza, Nuovo progetto, Attivazio-
ne, Da discutere, Milestone);
∗ la data di scadenza del task;
∗ la data di previsione finale per lo svolgimento del task;
∗ il soggetto;
∗ il contesto;
∗ il contenuto.
Figura 1.6: Visualizzazione di un task all’interno del GTD aziendale.
Questo sistema di gestione di progetto è stato inoltre integrato con la pagina web di
assistenza clienti. Tale pagina permette ai clienti di creare dei to do che rappresentino
le richieste o segnalazioni di errori, che verranno ricontattati qualora il task sia portato
a termine da parte del team di sviluppo, che aprirà la relativa issue.
Gitlab All’interno delle dinamiche aziendali la piattaforma GitLab è stata usata
principalmente per la creazione e la gestione delle issues, ossia quei problemi concernenti
nuove idee, domande, malfunzionamenti e funzioni di supporto. Anche in questo caso le
persone registrate al sistema avranno la possibilità di aprire una nuova issue che verrà
registrata in una pagina apposita a cui tutti i membri del sistema possono accedere.
Per una nuova issue si possono quindi definire le seguenti caratteristiche:
∗ il titolo;
∗ la descrizione;
∗ la priorità;
∗ specificare se assegnarla a qualche membro;
∗ una milestone;
∗ data di completamento prevista.
Una volta che una determinata issue verrà portata a termine si potrà segnare come
chiusa e verrà automaticamente rimossa dalla lista.
Gestione di versione
Come strumento di versionamento del codice, l’azienda utilizza il software di controllo
Git. Attualmente tutti i progetti sviluppati dall’azienda risiedono su repository gestite
da GitLab. La versione utilizzata dall’azienda è quella di tipo enterprise, disponibile
gratuitamente sotto licenza Open Source.8 CAPITOLO 1. IL CONTESTO AZIENDALE
Figura 1.7: Logo di GitLab
(https://about.gitlab.com/)
Le funzionalità offerte dal servizio Git e utilizzate dall’azienda sono le seguenti:
∗ offline-working: è possibile continuare a lavorare al compito che si sta svolgendo
anche nel caso in cui non sia presente la connessione al momento dell’operazione
eseguita, solo che non può avvenire la sincronizzazione sulla corrispondente
repository, che avverrà al ripristino della connessione;
∗ sviluppo distribuito: Git dà a ogni sviluppatore una copia locale dell’intera
cronologia di sviluppo, e le modifiche vengono copiate da un tale repository a
un altro. Queste modifiche vengono importate come diramazioni aggiuntive di
sviluppo, e possono essere fuse allo stesso modo di una diramazione sviluppata
localmente.
∗ gestione di grandi progetti: Git è molto veloce e scalabile per la gestione di
progetti di elevate dimensioni;
∗ branch e merge: il branch è un ramo in cui si può deviare lo sviluppo di un
prodotto, in modo da poter lavorare liberamente senza aver paura di rendere
instabile la versione del prodotto. Una volta che non si ha più la necessità di
lavorare in un ramo diverso da quello principale e si è portato a termine il proprio
compito si può eseguire l’operazione di merge, che permette di riunire il ramo
secondario con quello principale, sincronizzando il prodotto sviluppato;
Figura 1.8: Operazioni di branch e merge
∗ fork e pull request: sono due operazioni fondamentali. Il comando fork permet-
te di clonare una repository libera e/o Open Source sul proprio spazio, mentre
la pull request permette di proporre eventuali modifiche scritte sulla propria1.5. RAPPORTO CON LA CLIENTELA E PROPENSIONE ALL’INNOVAZIONE9
repository e che dovranno essere approvate dal responsabile del progetto affinchè
queste possano essere salvate.
Ambienti di sviluppo
Fin dagli albori non è stata imposta alcuna limitazione per quanto riguarda la scelta
degli ambienti di sviluppo da parte dell’azienda, pertanto di seguito verranno elencate
le principali tecnologie utilizzate, concordate dal team di sviluppo.
Sviluppo Android Per lo sviluppo di applicazioni Android l’Integrated Development
Environment è stato utilizzato il framework Android Studio. E’ attualmente l’Integrated
Development Environment ufficiale per lo sviluppo di applicazioni con tale sistema
operativo. E’ di proprietà di Google e permette lo sviluppo di applicazioni in Java
e Kotlin. Oltre alle funzioni native di sviluppo per il sistema operativo Android,
questo Integrated Development Environment permette di versionare il proprio codice
direttamente dalla finestra di sviluppo tramite Git, e la gestione della continuous
integration attraverso Jenkins.
Sviluppo iOS Per quanto riguarda lo sviluppo della versione iOS di ZotSell e degli
altri prodotti aziendali, viene utilizzato l’Integrated Development Environment Xcode.
Esso è completamente sviluppato e mantenuto da Apple, contenente una suite di
strumenti utili allo sviluppo di software per i sistemi macOS, iOS, watchOS e tvOS.
Sviluppo web Per quanto riguarda lo sviluppo web si è deciso principalmente di
utilizzare l’Integrated Development Environment IntelliJ IDEA, software sviluppato
dall’azienda JetBrains e tuttora in continuo aggiornamento.
1.5 Rapporto con la clientela e propensione all’inno-
vazione
Tradenet offre un servizio mirato alla personalizzazione del prodotto richiesto dai clienti
nei minimi dettagli. La tipologia dei clienti di Tradenet va dalle grandi aziende alle
piccole realtà. Qualunque sia il settore in cui lavorino, quasi la totalità di questi però
sono accomunati dalla necessità di migliorare i propri processi interni (dalla gestione
delle risorse alla vendita), per ottimizzare i propri punti deboli ed affermarsi nel settore.
E’ proprio per questo motivo che Tradenet non solo fornisce lo strumento adatto a
questa esigenza, ma anche un supporto su come utilizzarlo, grazie ad esempi di strategie
di marketing. Tra i migliori benefici riportati dai clienti che utilizzano l’attuale versione
di ZotSell risultano i seguenti:
∗ Riduzione dei costi di inserimento degli ordini;
∗ Riduzione degli insoluti;
∗ Riduzione dei tempi di incasso;
∗ Diminuzione degli errori di attribuzione prezzi;
∗ Diminuzione di scorte di magazzino;
∗ Aumento delle vendite.10 CAPITOLO 1. IL CONTESTO AZIENDALE
L’azienda è inoltre alla continua ricerca di nuove tecnologie e prodotti innovativi,
sia per quanto riguarda l’utilizzo interno, sia per le esigenze di mercato.
Tradenet è completamente favorevole alla ricerca ed allo sviluppo di tutto ciò che
possa dare un valore aggiunto alla creazione e al mantenimento dei prodotti. A
dimostrazione di questo fatto c’è la prova che molte parti di codice di ZotSell, dopo che
il team di sviluppo aziendale decise di utilizzare il nuovo linguaggio di programmazione
Kotlin per una questione di funzionalità, vennero subito convertite in quanto scritte
precedentemente in Java. Per comprendere al meglio gli effetti positivi della scelta
intrapresa, è il secondo anno che l’azienda concede l’opportunità a due sviluppatori
di partecipare alla KotlinConf, per essere sempre all’avanguardia nei vari campi di
sviluppo.
Per quanto riguarda la concorrenza, invece, l’azienda si prefigge l’obiettivo di creare
nuovi prodotti al passo con le esigenze di potenziali clienti posizionati su un mercato
in continua fase di evoluzione. Proprio per questo è stato sviluppato un modulo
dell’applicazione chiamato Attività, che permette di inserire qualunque forma di dato
l’utente voglia per poi inviarlo al server del cliente.Capitolo 2
Lo stage nella strategia
aziendale
2.1 Vantaggi aziendali
E’ il secondo anno che Tradenet decide di attivare progetti di stage universitario per
ottenere benefici all’interno del team di sviluppo e dell’azienda stessa.
Il primo vantaggio si colloca sicuramente all’interno dell’area di ricerca e sviluppo. Molte
delle tecnologie utilizzate da Tradenet all’interno dei propri progetti (come ad esempio
librerie o Framework) sono ormai datate e non sono più in fase di aggiornamento.
Questo deficit spesso provoca difficoltà nell’eseguire compiti che potrebbero essere risolti
con nuove tecnologie più adeguate e create ad hoc per risolvere uno stesso problema.
Agli stagisti è chiesta una particolare attenzione alla scelta di nuovi strumenti che
permettano loro di eseguire efficacemente il progetto assegnatogli. Essendo un’azienda
di piccole/medie dimensioni, Tradenet non dispone di risorse che possano continuamente
soffermarsi sulla ricerca e sullo sviluppo di nuove tecnologie, e l’assunzione di stagisti
universitari mette questa esigenza in primo piano, stimolando i diretti interessati a
trovare e proporre nuove soluzioni.
Il secondo vantaggio che l’azienda ha riscontrato con l’attivazione degli stage universitari
è stato il fatto di aver l’opportunità di inserire nuove risorse nel proprio organico che
arrivino direttamente dal mondo universitario, e abbiano un buon approccio alla
metodologia di studio e alla risoluzione dei problemi. Tramite un confronto diretto
con i vari membri all’interno del team di sviluppo ci si è accorti che suppur ci sia una
forte mancanza di esperienza da parte degli stagisti universitari, il loro lavoro è stato
integrato efficacemente da programmatori più esperti che hanno saputo dare buone
indicazioni nei momenti di maggiore difficoltà.
Il terzo vantaggio principale che si è riscontrato all’interno dell’azienda è che essendo il
lavoro in continua crescita ed avendo molte richieste da parte di clienti, nel caso in cui
lo stage attivato porti a risultati positivi viene periodicamente fatta una proposta di
assunzione allo stagista interessato, che avrà l’opportunità di inserirsi in una realtà
aziendale ancora prima della laurea stessa. Questi benefici sono stati discussi durante
una riunione con il tutor aziendale, il responsabile del settore di sviluppo, e gli stagisti
universitari presenti all’interno dell’azienda tra settembre e novembre. E’ emerso che
tutti i partecipanti al discorso sono rimasti soddisfatti dell’esperienza vissuta, e nel
mio caso personale è stata fatta una proposta di assunzione a lungo termine.
1112 CAPITOLO 2. LO STAGE NELLA STRATEGIA AZIENDALE
2.2 Presentazione del progetto
ZotSell è l’applicazione di punta dell’azienda; per esigenze di clienti e di mercato lo
sviluppo di quest’ultima è stato molto lungo (l’applicazione è nata 8 anni fa), e per
via dei numerosi cambi effettuati dalla sua nascita ad ora, sia nella codifica che nella
progettazione architetturale, non è mai stata implementata una suite che permettesse
di eseguire test automatici. Questo è stato un enorme problema in determinati momenti
critici, perchè per individuare alcuni errori è stato speso molto più tempo di quanto
si fosse previsto appunto per la mancanza di test. Lo stage è diviso in tre punti
fondamentali:
∗ analizzare il funzionamento dell’applicazione e definire una lista di test di unità
e per la UI atti ad identificare il maggior numero di problemi;
∗ codificare la suite di test definiti in precedenza;
∗ progettare e realizzare un sistema di continuous integration e continuous delivery
automatico.
Per Tradenet era fondamentale che venissero portati a termine i precedenti incarichi,
in quanto per esigenze di tempo è un problema che non era mai stato affrontato
prima. Gli sviluppatori Android interni all’azienda hanno sempre avuto una mole di
lavoro tale che non gli è mai stato concesso di avere un carico di 300 ore (pari ad uno
stage universitario), per potersi occupare della questione. E’ stato quindi non solo un
progetto utile all’azienda ma anche allo stagista, che nel mio caso ha potuto interessarsi
all’area di sviluppo preferita e analizzare interamente un’applicazione Android, fino
ad arrivare al completamento degli obiettivi prefissati in un percorso affiancato da
professionisti del settore.
2.2.1 Analisi dell’applicazione
Nella prima settimana di stage l’obiettivo principale consiste nell’analizzare l’applica-
zione ZotSell. Di questa è importante dividere due passi principali:
∗ La familiarizzazione con l’attuale struttura del codice operativo;
∗ L’identificazione dei casi d’uso di maggior importanza per l’azienda.
Innanzitutto è importante vedere l’applicazione funzionare su un dispositivo Android
mobile (smartphone e tablet), e capirne le funzionalità. Ancora prima di vedere il
codice, il primissimo obiettivo sarà quello di cogliere i meccanismi di funzionamento
dell’applicazione e tenerli bene a mente. Per poter lavorare in maniera efficace è
chiesto allo stagista di comprendere a fondo i casi d’uso relativi all’applicazione, la
loro organizzazione e implementazione all’interno del software stesso. Successivamente
sarà necessario uno studio preliminare del codice, per poter intervenire laddove altri
programmatori hanno lavorato prima dello stagista, in modo da non creare incongruenze
strutturali e funzionali. In seguito all’analisi dell’applicazione si passerà allo studio
dell’architettura e del modello di progettazione utilizzato.2.2. PRESENTAZIONE DEL PROGETTO 13
2.2.2 Analisi dell’architettura
Oltre all’analisi del codice è fondamentale comprendere l’architettura in cui questo è
organizzato. Per lo sviluppo dell’applicazione è stato seguito il modello della Clean
Architecture, ideato da Robert C. Martin.
Figura 2.1: Rappresentazione grafica della Clean Architecture.
Il modello prevede che il software sia separato in vari livelli. In particolare un
software che viene costruito con questo modello otterrà le seguenti caratteristiche:
∗ Indipendente da Framework: l’architettura non dipende dall’esistenza di
alcune librerie di software a funzionalità elevata;
∗ Verificabile: il software deve essere verificabile in ogni sua minima unità;
∗ Indipendente dall’interfaccia utente: l’interfaccia utente può cambiare
facilmente, senza modificare il resto del sistema.
∗ Indipendente dal database: non si impone nessuna dipendenza stretta nel
rapporto col database utilizzato;
∗ Indipendente dall’esterno: il software prodotto non ha alcuna dipendenza da
componenti esterne.
Come l’esempio riportato nell’immagine sovrastante, i cerchi concentrici rappresen-
tano diverse aree del software. Tra queste aree vige in ogni momento la regola delle
dipendenze, secondo la quale le dipendenze del codice sorgente possono solo puntare
verso livelli interni. Niente in una cerchia ristretta può sapere qualcosa di un cerchio
esterno. In particolare, qualsiasi nome dichiarato in un cerchio esterno non deve essere
menzionato dal codice in un cerchio interno. Ciò include funzioni, classi variabili, o
qualsiasi altra entità software denominata. Tutto il codice che dovrà essere prodotto
durante il periodo di stage, per la codifica dei test individuati e per risolvere i problemi
incontrati tramite l’esecuzione dei test stessi, necessita di rispettare l’utilizzo della
Clean Architecture in ogni sua forma.14 CAPITOLO 2. LO STAGE NELLA STRATEGIA AZIENDALE
2.2.3 Individuazione e codifica dei test
Il secondo obiettivo riguardante lo stage comprende l’individuazione e la codifica dei
test di interfaccia e di unità per l’applicazione ZotSell. I test di unità sono molto
numerosi in un’applicazione di tali dimensioni e quindi la rispettiva codifica necessita di
una grande quantità di tempo per eseguire correttamente quanto previsto. La maggior
parte dei problemi dell’applicazione è legata ai test di unità: essi sono fondamentali
per avere un riscontro sulla copertura del codice e capire se ed in quali punti viene
violato il concetto di Clean Architecture, causando malfunzionamenti o bug all’interno
dell’applicazione. I test di unità si possono suddividere in due categorie:
∗ test funzionali: fanno riferimento alla specifica di un’unità e osservano il suo
comportamento dall’esterno;
∗ test strutturali: verificano la logica interna del codice dell’unità. Perseguono la
massima copertura del codice sorgente.
La totalità dei test realizzati verranno integrati in apposite directory all’interno del
progetto.
2.2.4 Progettazione di un sistema di CI/CD
In seguito alla realizzazione della suite di test l’ultimo obiettivo di stage prevede la
produzione di codice in grado di permettere l’esecuzione di tali test all’interno di
un sistema di continuous integration e continuous delivery automatizzato tramite la
piattaforma di versionamento del codice GitLab. Tale sistema avrà il compito di
eseguire i test nei momenti più adatti decisi dallo sviluppatore al fine di garantire che
solamente del codice conforme alle direttive aziendali sia reso pubblico sotto la forma
di applicazioni compilate.
Figura 2.2: Principi base di un sistema di Continuous Integration e Continuous Delivery.2.3. ASPETTATIVE AZIENDALI 15
2.3 Aspettative aziendali
Al termine delle 300 ore di stage l’azienda si aspetta di avere una batteria completa di
test di unità e test di interfaccia per l’applicazione ZotSell.
Tradenet è particolarmente interessata allo sviluppo di questo progetto per via del
carico di lavoro che viene portato avanti quotidianamente in azienda; con un corretto
svolgimento del piano di lavoro verrebbe sicuramente alzata la produttività totale, in
quanto gli sviluppatori che stanno attualmente lavorando su diversi moduli avrebbero
l’opportunità di eseguire dei test automatici ad ogni commit, senza preoccuparsi di
verificare manualmente la presenza di errori prima di versionare il proprio codice.
Inoltre, nel caso in cui si presentassero bug o malfunzionamenti, basterebbe andare ad
eseguire i test sviluppati, in maniera da poter operare tempestivamente nel punto in
cui ha avuto origine l’errore, cosa che ora non è possibile data la quasi totale assenza
di test.
Figura 2.3: Integrazione di una suite di test con un sistema di CI/CD
Oltre a questo, l’azienda è molto interessata a valutare la capacità di problem solving
da parte di studenti alle prime armi; il loro approccio per quanto semplice potrebbe
risultare innovativo, perciò non ha imposto particolari vincoli a livello di tecnologie o
metodi di ragionamento.
Sono stati quindi concordati dopo un primo colloquio preliminare con il tutor
aziendale i seguenti obiettivi:16 CAPITOLO 2. LO STAGE NELLA STRATEGIA AZIENDALE
Obiettivi obbligatori
Realizzazione di una lista di test di unità necessari da realizzare, dotati ciascuno di
breve descrizione del caso d’uso, degli input previsti e degli output attesi
Realizzazione di una lista di test legati all’interfaccia grafica necessari da realizzare,
dotati ciascuno di breve descrizione del caso d’uso, degli input previsti e degli output
attesi
Codifica di almeno il 75% dei test di unità descritti
Codifica di almeno il 50% dei test legati all’interfaccia descritti
Obiettivi desiderabili
Codifica della totalità dei test di unità descritti
Codifica della totalità dei test legati all’interfaccia grafica descritti
Progettazione di un sistema di CI/CD basato su Gitlab atto ad eseguire i test
codificati nei momenti migliori identificati dall’utente
Obiettivi facoltativi
Realizzazione del sistema di CI/CD precedentemente progettato
Tabella 2.1: Obiettivi dello stage fissati da Tradenet.
2.4 Vincoli
2.4.1 Vincoli metodologici
Per lo svolgimento dell’attività di stage è stato imposto il vincolo che lo studente
dovesse essere presente in azienda per poter lavorare.
Questa decisione è stata presa al fine di favorire lo studente, che essendo alle prime
armi in ambito lavorativo ha spesso bisogno di un confronto diretto con persone più
esperte. In questo modo lo stagista può avere l’opportunità non solo di essere soccorso
nei momenti di bisogno, ma anche di osservare da vicino come lavorano programmatori
con decine di anni di esperienza sia a livello individuale che in team.
Oltre a ciò, l’azienda ha richiesto che quotidianamente venisse riempito un piccolo
modulo per capire come erano state spese le ore della giornata, e per poter fare delle
stime future riguardo al tempo medio degli incarichi assegnati. In aggiunta, ogni
venerdì lavorativo durante il periodo di stage è stata fatta una riunione frontale con il
tutor aziendale, per illustrare i progressi fatti e le problematiche incontrate. Al termine
dell’ultima settimana lavorativa, inoltre, è stato richiesto da parte dell’azienda di
illustrare i progressi fatti al team di sviluppo Android tramite una piccola presentazione
che rendicontasse l’utilità del lavoro fatto durante il periodo di stage.
2.4.2 Vincoli temporali
Lo stage deve avere una durata complessiva di 300 ore. E’ stato deciso assieme al
tutor aziendale che la giornata lavorativa sarebbe durata dalle ore 09:00 alle ore 18:00,
tenendo conto di un’ora di pausa pranzo, dal lunedì al venerdì. In questo modo è stato
possibile concentrare 40 ore di lavoro a settimana per un totale di 7 settimane (280
ore), aggiungendo un’ulteriore settimana di 3 giorni per completare le 20 ore rimanenti.
Prima dell’inizio dello stage mi è stato consegnato un breve piano di lavoro dall’azienda
per una suddivisione del tempo nel seguente modo:2.5. ASPETTATIVE PERSONALI 17
∗ prima settimana: analisi dell’attuale base codice dell’applicazione;
∗ seconda-terza settimana: definizione dei test;
∗ quarta-sesta settimana: codifica dei test;
∗ settima settimana: progettazione della continuous integration/continuous
delivery.
Durante l’effettiva esecuzione di questi incarichi però ci si è accorti che la definizione
dei test richiedeva meno tempo di quanto previsto, che è stato speso più correttamente
nello studio di strumenti e librerie che permettessero di compiere gli incarichi affidati
per la fase di codifica. L’effettiva esecuzione della codifica dei test ha richiesto uno
sforzo maggiore di quanto pianificato inizialmente, sia per l’utilizzo di tecniche come
la dependency injection, sia per l’utilizzo di librerie all’avanguardia ma ancora senza
documentazione che hanno richiesto notevoli sforzi per l’apprendimento.
Figura 2.4: Diagramma di Gantt dello stage.
2.4.3 Vincoli tecnologici
L’azienda non ha imposto particolari vincoli tecnologici. Per il settore di sviluppo
Android è stato consigliato un appropriato Integrated Development Environment, e
sono stati forniti gli strumenti per poter configurare correttamente il progetto sulla
propria macchina. E’ stato comunque all’utente scegliere quali Framework e librerie
utilizzare per la risoluzione dei problemi proposti. Al contrario, l’azienda è rimasta
entusiasta del fatto che uno stagista fosse autonomo e potesse scegliere senza vincoli
quali strumenti utilizzare. Ogni scelta intrapresa è stata in tutti i casi concordata
con il responsabile del team di sviluppo Android, in maniera che ci fosse un continuo
dialogo e non nascessero discrepanze. In questo modo il lavoro è proceduto in maniera
eccellente, senza che si creassero grandi intoppi.
2.5 Aspettative personali
Mi sono attivato alla ricerca di uno stage universitario durante la primavera 2018,
partecipando inizialmente all’evento Stage-IT, organizzato dall’Università degli studi
di Padova. Durante questa giornata ho avuto la possibilità di conoscere svariate
aziende del territorio, suddivise per categoria di campo applicativo. Inizialmente non
avevo trovato nessuna proposta che mi lasciasse completamente soddisfatto; in quanto
fortemente interessato allo sviluppo Android, ho fatto il colloquio con qualche azienda
del rispettivo settore, ma o le date erano restrittive rispetto al mio piano di studio, o il
luogo non era per me facilmente raggiungibile.
In seguito a questa esperienza, durante un dialogo con uno studente del mio stesso18 CAPITOLO 2. LO STAGE NELLA STRATEGIA AZIENDALE corso di laurea dell’anno precedente, mi è stato proposto di fare un colloquio per l’azienda in cui egli era stato assunto a tempo pieno, in quanto c’era la forte necessità di una risorsa che venisse inserita all’interno del team di sviluppo Android. Dopo un breve colloquio con il responsabile del team, e l’amministratore dell’azienda è nato l’accordo per iniziare uno stage all’inizio di settembre. Essendo questa la mia prima esperienza lavorativa nell’ambito informatico, nel bagaglio personale ho ritrovato molta teoria studiata durante gli anni universitari, ma poca pratica fatta per lo più in piccoli progetti. La prima considerazione che mi sorge spontaneo fare dopo aver frequentato lo stage, è che approcciarsi al mondo del lavoro è un metodo molto efficace per poter apprendere nozioni complicate, purchè queste siano affiancate da un continuo studio individuale. Nel mio preciso caso è risultato chiaro fin dal primo momento che avrei dovuto sforzarmi molto per mettere in pratica le nozioni che avevo acquisito durante gli anni di studio precedenti. La prima grande difficoltà di questo stage è stata quindi passare a mettere in pratica alcune nozioni di teoria, e nonostante avessi appreso bene la maggior parte dei concetti richiesti per svolgere gli incarichi affidati, non è stato un processo immediato. L’applicazione di tecnologie mai viste prima, su progetti di grandi dimensioni e nati molti anni fa ha richiesto una notevole quantità di tempo e di errori prima di portare a soluzioni sufficienti. E’ stato allo stesso tempo molto stimolante aver un problema da risolvere e cercare il modo migliore per agire in base alla soluzione progettata.
Capitolo 3
Resoconto dello stage
3.1 Pianificazione del progetto
Assieme al tutor aziendale durante il mese di agosto 2018, sono stati decisi i requisiti
obbligatori, desiderabili e facoltativi da completare entro il periodo di stage, per una
durata complessiva di 300 ore.
Ho avuto quindi più di un mese per poter effettuare un lavoro preliminare rispetto al
piano di stage, cercando di focalizzarmi sull’apprendimento degli strumenti che avrei
dovuto utilizzare.
E’ stato quindi importante iniziare lo stage con un’adeguata preparazione, soprattutto
per quanto riguarda il linguaggio di programmazione Kotlin e l’Integrated Development
Environment Android Studio. In questo modo la preventivata pianificazione non ha
subito ritardi iniziali per motivi di competenze.
3.2 Analisi dell’applicazione in dettaglio
Il primo obiettivo per cui erano state preventivate le 40 ore iniziali consiste in uno
studio dell’applicazione, che è diviso nelle seguenti parti:
∗ Familiarizzazione con l’attuale struttura del codice operativo.
∗ Identificazione dei casi d’uso di maggior importanza per l’azienda.
In seguito allo svolgimento degli incarichi ho affiancato altri punti fondamentali, di cui
ho riconosciuto l’importanza dopo l’effettiva realizzazione del progetto di stage.
3.2.1 Apprendimento delle tecnologie e dei framework utiliz-
zati
Prima ancora di poter mettere mano al progetto è stato richiesto di prendere fa-
miliarità con l’Integrated Development Environment Android Studio, per far sì che
si comprendessero le funzioni del principale strumento di sviluppo ed i linguaggi di
programmazione utilizzati al suo interno.
1920 CAPITOLO 3. RESOCONTO DELLO STAGE
3.2.2 Familiarizzazione con la struttura del codice operativo
Innanzitutto come prima attività è stata richiesta una familiarizzazione con la struttura
dell’intera applicazione, a partire dall’architettura e organizzazione dei componenti
fino al loro funzionamento. Essendo ZotSell un’applicazione di grandi dimensioni,
purtroppo non è stato possibile entrare in dettaglio di tutti i moduli di cui essa è
composta, ma solo di quelli fondamentali per capirne il funzionamento. Il primo
giorno, per verificare che le competenze elementari del linguaggio Kotlin fossero state
assimilate, mi sono stati assegnati degli esercizi da risolvere esterni allo stage che
racchiudevano le funzioni principali del linguaggio. In seguito alla loro risoluzione mi è
stato illustrato il concetto di Clean Architecture, e come fosse stato rispettivamente
applicato per evitare dipendenze di alto livello, che comportassero gravi forme di errori
a cascata. In seguito mi è stato fornito l’accesso alla repository sulla piattaforma di
versionamento GitLab per scaricare l’applicazione sul mio dispositivo ed iniziare ad
ispezionare l’organizzazione del codice ed i suoi casi d’uso principali.
3.2.3 Identificazione dei casi d’uso di maggiore importanza
Come secondo obiettivo è stato imposto di identificare i principali casi d’uso dell’appli-
cazione e comprenderne il relativo funzionamento attraverso i componenti organizzati
secondo la Clean Architecture. Per portare a termine questo compito si sono prese due
strade:
1. La consegna di un dispositivo Android con l’applicazione installata per verificarne
il funzionamento pratico tramite l’utilizzo;
2. L’ispezione del codice e dell’interazione fra i vari componenti.
Inizialmente mi è stato quindi concesso di poter provare l’applicazione con le mie
stesse mani, cercando di capire la logica alla base dell’applicazione e le sue funzioni
principali. Tutto questo è stato integrato dalla verifica del relativo codice e delle
meccaniche principali che vedevano come protagonisti gli UseCase, i Fragment ed i
Presenter.3.3. DEFINIZIONE DEI TEST 21
Figura 3.1: Schermata contenente gli usecase riguardanti il modulo di login.
3.2.4 Sul concetto di Inversione del Controllo
Oltre ai due paragrafi precedenti, in cui sono state descritte le mansioni svolte durante
la prima settimana presso la Tradenet, ne ho aggiunto un terzo per evidenziare il primo
ostacolo in cui mi sono imbattuto fin da subito principalmente per una mancanza
di esperienza sul campo. Ad affiancare il concetto di Clean Architecture è molto
importante aggiungere quello di Inversione del Controllo, che permette di rendere le
componenti software il più indipendenti possibile, affinchè si possa modificarne solo una
parte senza dover toccare anche le altre. In particolare all’interno di ZotSell, l’Inversione
del Controllo è stata effettuata tramite la tecnica della Dependency Injection. L’idea
alla base di questa tecnica è quella di avere un componente esterno (denominato
assembler) che si occupi della creazione degli oggetti e delle loro relative dipendenze e
di assemblarle mediante l’utilizzo dell’injection. Questo è stato fatto tramite l’utilizzo
della libreria Dagger, tranne che per il modulo di login, per il quale mi è stato affidato
il compito di implementarne l’utilizzo per proseguire in seguito con l’implementazione
dei test, in cui parlerò meglio nei prossimi paragrafi.
3.3 Definizione dei test
Per quanto riguarda la definizione dei test è stato richiesto lo sviluppo di:
∗ Test di unità: Per verificare il corretto funzionamento della parte logica
dell’applicazione
∗ Test di interfaccia grafica: Per verificare il corretto funzionamento della User
Interface.
3.3.1 Definizione dei test di Interfaccia Grafica
In questo paragrafo invece viene spiegato come è stato perseguito l’obiettivo di definire
i vari test di interfaccia relativi alle componenti grafiche dell’applicazione. Per questo22 CAPITOLO 3. RESOCONTO DELLO STAGE
tipo di test è stato utilizzato sia un dispositivo Android su cui girava l’applicazione,
per poter effettivamente verificare come risultassero le componenti grafiche all’utente
finale, sia l’ispezione del codice relativo alla parte grafica (composta principalmente
da Fragment). I test di interfaccia si possono raggruppare nella branca del black-box
testing, senza quindi aver la necessità di accedere alle risorse del progetto su cui si
sta lavorando. Personalmente ho preso la decisione di accedere comunque alla parte
che identificasse l’interfaccia grafica per poter capire più in dettaglio le proprietà e
la disposizione dei componenti all’interno delle finestre, essendo stata la mia prima
esperienza con un’applicazione Android.
Figura 3.2: Tabella contenente alcuni test di interfaccia relativa al modulo ordini.
3.3.2 Definizione dei test di unità
In questo paragrafo verrà esposto il metodo tramite il quale sono stati individuati i test
di unità relativi all’applicazione ZotSell. Innanzitutto è stato necessario comprendere
quali fossero le parti costituenti dell’applicazione e come interagissero tra loro. Questo si
è rivelato un compito inizialmente complicato, poi tramite lo sviluppo di alcuni disegni
esplicativi è diventato via via sempre più chiaro. Per capire alcune funzionalità è stato
importante studiare alcune librerie utilizzate dai programmatori. Tra le più utilizzate
troviamo inoltre alcune librerie sviluppate completamente all’interno dell’azienda.
Inizialmente mi sono trovato ad ispezionare le classi relative alle varie unità dei relativi3.3. DEFINIZIONE DEI TEST 23 moduli, i loro metodi, e le loro implementazioni. Di volta in volta ho iniziato a definire una lista di test da poter in seguito implementare relativi al corretto funzionamento dei componenti. Alla fine di ogni giornata ho avuto un confronto diretto con uno degli sviluppatori presenti all’interno del team, con cui discutevo riguardo i test individuati e dei possibili modi in cui avrei potuto implementarli.
24 CAPITOLO 3. RESOCONTO DELLO STAGE
Implementazione della libreria Dagger, per il modulo di Login
Per prendere mano con il concetto di Clean Architecture e la relativa tecnica di
Dependency Injection, mi è stato chiesto di implementare tale strategia all’interno del
modulo di login, per il quale non era ancora stata utilizzata la tecnica di Inversione
del Controllo. Il primo passo è stato studiare la documentazione ufficiale della libreria
e cercare esempi pratici che potessero chiarirmi con quali componenti lavorare e in che
modo. Tramite la repository pubblica situata sulla piattaforma Github della libreria
Dagger ho quindi seguito le istruzioni per l’implementazione dell’injection all’interno di
un applicativo Android. Per ottenere un risultato positivo è stato necessario modificare
l’Activity principale, ed implementare nuove classi (chiamate principalmente moduli)
che permettessero la relativa modifica della gerarchia per consentire all’injector di
risolvere le dipendenze create. L’intero processo ha richiesto più di un giorno di lavoro
che però è stato risparmiato per il completamento in tempi più brevi rispetto a quanto
prefissato del precedente compito di definizione dei test.
Figura 3.3: Schema generale del funzionamento di Dagger.
3.3.3 Anticipo imprevisto sulla tabella oraria
Per eseguire i precedenti compiti è stato richiesto un totale di circa 100 ore, rispetto
alle 128 prefissate dal piano di lavoro redatto dal tutor aziendale. Queste ore sono
state pienamente ridistribuite all’interno della fase di codifica, in quanto ha portato
alla scoperta di numerosi problemi che hanno richiesto uno sforzo maggiore, e quindi
circa i due terzi del tempo totale concesso.
3.4 Codifica dei test
La maggior parte dello stage, dopo aver preso familiarità con il codice dell’applicazione
ed aver definito una batteria di possibili test di unità e di interfaccia da implementare,
si è incentrata sulla codifica. La codifica, come per i test, è stata divisa nelle seguenti
categorie:
∗ Codifica dei test di unità e correzione degli eventuali errori riscontrati durante la
loro esecuzionePuoi anche leggere
