Componente ID Unit

[f.faleschini]

Come anticipato in Componente MD WS API - n°3 da f.faleschini creo questo argomento per avere un contenitore community per lo sviluppo del componente IDUnit.

IDUnit è un componente che abbiamo sviluppato internatmente in Nord Est Systems e nasce come semplice framework di unit test.

Non è un porting completo dei framework “veri” come Junit ma ha solo, per ora, un sottoinsieme delle feature, ovvero consente di realizzare delle suite di unit test che sono molto utili per tenere sotto controllo progetti grandi e soprattutto componenti usati senza sorgenti in molti progetti.

Mancano molte cose che servono per fare un framework completo, ad esempio “mock”, “code coverage” non ci sono (e forse non ci saranno mai?) ma già così il componente ha la sua utilità.

Questo post è solo un annuncio, a breve pubblicherò un video per spiegare in pochi minuti cos’è il componente, come si usa e perché serve.

Quindi lo pubblicheremo su Teamworks.

Ciao.

PS @paolo.giannelli non riesco a vedere la categoia “Progetti open source” quindi lo lascio “Senza categoria”, me lo puoi modificare tu per favore? Grazie!

Versioni di ID Unit per chi non ha una versione Team Works di Instant Developer Foundation.

ID Unit 24_5.zip (628,5 KB) aggiornata al 14-feb-2025 alle 14:58.

[paolo.giannelli]

@f.faleschini prova ora ad assegnare la categoria.

[f.faleschini]

Categoria assegnata, grazie.

Finalmente sono riuscito a caricare Id Unit.

Ho fatto un video per introdurre il componente, il video dura 16 minuti ma lo reputo il modo migliore per rompere il ghiaccio con il componente, spero che sia utile.

Eccolo qui: Presentazione componente Id Unit - YouTube

Come spiego nel video ho scelto di caricare due componenti quasi uguali:
Id unit dev - la versione da modificare per introdurre novità
id Unit 22.0 - la versione branchata (ho fatto un vero branch su teamworks) da usare in produzione

questo è il modo in cui noi gestiamo i componenti: un dev per le modifiche e N branch per l’uso in produzione. Propongo questo approccio almeno per i nostri componenti, questo ci aiuterebbe a smettere di usare il nostro teamworks e a usare quello di community più facilmente.

Cosa ne pensate di id Unit?

Il codice .net e java che parsa gli id Form per trovare i metodi di test è scritto molto a picconate, ma funziona.

Al momento per noi il componente è finito, però si potrebbero aggiugnere feature “pseudo Junit”, una lista breve di cose che IDUnit non fa è:

• supporto al code coverage
• supporto a mock
• supporto a stub

sono tutte cose molto grosse e a mio avviso neanche così importanti, visto che già IDUnit risolve molti problemi da solo, di certo non si è mai arrivati e si può fare di più.
In ogni caso ora che è un progetto community tutti potete dire la vostra e proporre una miglioria.

Mi piacerebbe comunque che almeno venga usato così com’è, noi abbiamo esperienza e possiamo dare un supporto.

Ecco l’idp del progetto di test che uso nel video. Il progetto usa IDUnit 22.0 importato senza sorgenti, oltre a quanto c’è nel video ho aggiunto un ulteriore metodo di test per mostrare l’uso di più assert in un unico metodo:
ID Unit Demo.zip (489,8 KB)

[paolo.giannelli]

@f.faleschini grazie di questo contributo così dettagliato e con addirittura un video di spiegazione dell’utilizzo del componente.

[paolo.giannelli]

A oggi 14-feb-2025 sul Team Works sono presenti le seguenti versioni:

• ID Unit DEV - la versione di sviluppo
• ID Unit 24.5 - la versione rilasciata in 24.5

[f.faleschini]

Riprendiamo quindi dopo oltre 2 anni il discorso ID UNIT.

Nel video che avevo fatto a suo tempo mostravo una vecchia versione id Unit e soprattutto allora il TDD non era ancora una pratica, quindi quella è “archeologia”.

Tanto per smuovere un po’ le acque faccio un po’ di condivisione.

Innanzitutto la ROADMAP di IDUnit che ho in testa e di cui non ho parlato al webinar (c’era una slide nella prima versione del powerpoint ma poi ho dovuto sfoltire per stare nei tempi).

ROADMAP ID UNIT FEBBRAIO 2025:
ALTA PRIORITA’:

• supportare il caso in cui a run time nessun Assert venga chiamato in una procedura di test: attualmente IDUnit ignora il caso e lascia PASS, ma dovrebbe mettere FAIL siccome se non viene eseguito un Assert significa che qualche eccezione è avvenuta e quindi non solo l’Assert non ha avuto succcesso, ma proprio c’è un macro errore (il workaround adesso è aprire comunque il debug anche se dice “All test passed” e vedere che non ci siano “errori rossi”), ma va migliorato
• se ci sono tanti form di test e io scelgo di lanciare solo i test di un gruppo, nel debug vedo tante richieste vuote quanti sono i gruppi “non selezionati”, andrebbe fatto i modo che si veda solo una richiesta (basta cambiare il funzionamento del timer che sta sotto a tutto). Se ho 50 test group e seleziono il 50esimo ho 49 richieste vuote e la 50esima “vera”.
• ci sono ancora procedure e proprietà pubbliche che andrebbero messe in una classe che le encapsuli
• creare gli Unit Test per Id Unit (che è stato sviluppato senza TDD) quindi almeno le nuove cose farle in TDD

BASSA PRIORITA’:

• poter selezionare più di un test group alla volta (ora solo uno)
• poter definire il test group di default (ora è sempre allTests)
• poter definire per ciascun test group se va eseguito in serversession o browsersession

questa era la roadmap, che però forse andrebbe messa in un thread a parte? Poi questa ce l’ho in testa, è la prima volta che la scrivo.

Ultima condivisone: sto finendo di realizzare il primo progetto di dimensioni importanti fatto da zero col TDD (ci lavoro da dicembre). È davvero un altro mondo, il codice risultante lo si può “addirittura mostrare al cliente”, in praticoalre la applicazione fa cose come prendere un pdf di 400 pagine, ognuna con la busta paga di un dipendente, spezzarlo in 400 file, leggere dentro ogni file per cercare il codice fiscale, associare ogni pagina a una persona, importare il file nel sw HR. Tutto lo sviluppo della manipolazione dei pdf l’ho fatto con il TDD, ma siccome c’è molta logica legata al contenuto dei file ho fatto una classe pdfFile estesa da realPdfFile e fakePdfFile, così tutta la parte complicata in cui non avere file pdf è più facile l’ho fatta con la classe fake e poi una volta finito ho implementato realPdfFile (inclusa l’abilità di spezzare un pdf, leggerci dentro e concatenare alcuni file) e automaticamente tutto ha funzionato. Boh, questa è solo una rapida condivisone, però il concetto è: con TDD lavori solo sulle classi e l’ultimo giorno, con la DO, fai le videate e la app è finita. Poi chiaro parlo di App in cui la videata può essere anche bruttina, se deve essere bellissima c’è molto più lavoro… Ciao!

[f.faleschini]

Ciao, approfitto per aggiornare questo thread per informare che mel mio idunit DEV (che tengo nel mio teamworks) ho implementato i primi 2 punti ad alta priorità dei 4 che ho elencato sopra. Quindi comunque il componente si evolve. Al momento per quanto mi serve ha praticamente tutte le feature importanti implementate, in effetti tutto il resto in roadmap è più “nice to have” che urgente. Detto questo allineare il dev a quello della community andrebbe fatto e in ogni caso non è un’operatività quotidiana usare più server teamworks in parallelo. In ogni caso ci tenevo ad aggiornarvi. Ciao!

[paolo.giannelli]

Grazie @f.faleschini dell’aggiornamento, poi quando riesce ad aggiornare anche quello in Community ci avvisi.