Newsgroup: it.comp.lang.c
Titolo: TDD in ambito C embedded

Ciao a tutti,
mi presento: mi chiamo Marco, ho lavorato per otto anni come programmatore C in ambienti embedded, poi C++, infine negli ultimi quattro anni ho lavorato in ambito più di alto livello (desktop clients) in C#. Ora lavoro in un'azienda come system integrator e sto cercando un modo per introdurre qualche metodologia di extreme programming, appresa in ambiente .net, tra i programmatori C embedded di questa azienda, in particolare il Test Driven Development, e anche una buona copertura di unit test su codice legacy già esistente.
Ho trovato qualche buon testo in rete, ma volevo chiedervi se qualcuno del newsgroup ha mai affrontato questo argomento e se conosce qualcuno (freelance, azienda) che faccia in Italia corsi o coaching sull'argomento (tipo questo negli USA: 
http://www.objectmentor.com/omTraining/course_agile_TTDCE.html
 
). 
Magari, se qui sono OT, sapete se c'è un newsgroup più specifico dove porre la domanda?
 
Marco

 
 
E' un po' OT, ma è comunque interessante ;)
 
Ciao!

 sull'argomento (tipo questo negli USA:
 
Io sto giusto sviluppando una libreria per l'unit testing in C, e di 
recente ho notato un libro che sembra avere ottime review:
http://amzn.com/193435662X
 
 
Dai un buon libro ad un buon programmatore, e lo farai felice!
 
 
Ciao  Manlio

Grazie a tutti per i consigli!
Proprio quel libro è appunto già stato preso da uno dei miei colleghi, che è rimasto "folgorato" da un workshop fatto presso uno user group della mia zona (XPUG Marche), dove abbiamo sperimentato, "mani sulla tastiera", il tdd con alcuni esercizi mirati: tenere sotto controllo gli errori di regressione sotto i propri occhi è stato convincente senza bisogno di grossi discorsi... Il tutto era però sviluppato in ambiente object oriented (c# con framework nunit per gli unit test).
Ora questo collega ha iniziato a fare alcune prove sul codice su cui lavora, senza framework ma con funzioni di test costruite ad hoc e abilitate/disabilitate tramite define, e sta già apprezzando il solo "automatizzare" grandi quantità di test su funzioni che maneggiano tabelle con una discreta quantità di dati. Ora, come obbiettivo, dopo la lettura del libro e di altri interessanti articoli con casi d'uso, vorremmo preparare una sorta di presentazione del tdd mirata per l'embedded da fare in azienda tra gli sviluppatori, magari in stile workshop, una cosa pratica.
 
Grazie ancora e buona giornata!
Marco

 Marco
 
Ciao  Manlio

 
 
A questo punto chiedo.. cosa non ti piace dell'interfaccia TAP della mia? :D
http://code.google.com/p/libmmp/source/browse/trunk/src/mmp_tap.h
 
 
La libreria in oggetto l'ho scritta anni fa, e devo dire che l'interfaccia
TAP in realtà l'ho usata solo per un breve periodo: è molto più comodo
scrivere i test in altri modi.. Anche la libreria in oggetto una volta
faceva auto-TAP-testing dopo la compilazione, ma ho rimosso tutto in
favore delle funzioni di check degli autotools.
In altri casi preferisco, sì, usare altri sistemi, e sinceramente il fatto
che i test non siano collegabili ad un tool di tracking in automatico non
è che mi pesi così tanto, anche se è strano da confessare :/
 
Ciao!


Comunque, dipende a che livello di "embedded" siete..
Se programmate su piattaforme su cui gira linux (o un qualsiasi altro S.O.
emulabile) puoi usare qualsiasi altro strumento che si usa nella
programmazione desktop o server.
Se programmate bare-metal idem, c'è solo da stare attenti al design del
codice per non finire in un #define-hell in breve tempo - questo lo aggiungo
per esperienza..
 
Ciao!

 [...]
 
 
Ciao  Manlio

 
 
Esiste un target speciale di make, il check, che può essere usato per il
test del compilato.
Se fai un browse del trunk a partire dal link che ti ho scritto prima puoi
vedere come ho fatto io il .am e i test_qualcosa.c, che sarebbero gli unit-test
veri e propri.
 
Ciao!


Ok, ma ancora non ho capito cosa intendevi dire con
"Anche la libreria in oggetto una volta
faceva auto-TAP-testing dopo la compilazione, ma ho rimosso tutto in
favore delle funzioni di check degli autotools."
 
Unita alla frase precedente:
"è molto più comodo scrivere i test in altri modi"
 
 
Gli unit test si scrivono come fai tu, ovviamente.
Devi avere un file sorgente per ogni test case, che verrà compilato in un 
eseguibile.
 
Poi ovviamente devi vedere come compilare in automatico e poi eseguire i 
test, ma questo non ha nulla a che vedere con il framework che usi per 
l'unit testing.  Cambiano solo i dettagli.
 
 
 
Ciao  Manlio

Il Tue, 29 Oct 2013 10:15:39 -0700, fmassei ha scritto:
 

Ho letto il codice sorgente di uno dei test.
Se qualcosa fallisce, come fai a sapere *cosa* ha fallito?
 
 
Ciao  Manlio


La granularità dell'output è a livello di test.
Anche questo non lo vedo come un gran problema: i test devono *sempre*
passare tutti, altrimenti si prende la singola unit e si va in debug su quella.
Se così non fosse avrei solo un milione di righe di output con scritto
"passed": che ci faccio? :)
 
In quel caso specialmente non c'è bisogno di avere una granularità più fine:
stiamo parlando di containers e funzioni wrappers, se non passa anche solo uno
dei test, mettiamo, sulla unit che riguarda le liste, probabilmente ci sono
in giro guai seri.
 
Ciao!

 
 
Sì, no, boh.
 
Formalmente hai ragione, forse la mia è solo una cosa di simpatia..
Se usi il "framework" del make check basta che l'applicativo di test esca
con 0 o EXIT_FAILURE, e hai fatto. Non devi nemmeno mettere scritte,
descrizioni o preoccuparti dell'output carino, che ti frega.
Con robe tipo il TAP invece ti preoccupi di più, devi gestire l'output, e
che fai, ora che ci sei non lo configuri un sistema di test coverage, magari
con logging, magari attaccando i risultati dei test alla documentazione, e via
dicendo? :)
 
Te l'ho detto, è solo preferenza mia.
Alla fine IMHO il concetto è che c'è bisogno di un sistema automatico di test
a valle della compilazione che ti dica se ci sono state regressioni o no,
e basta: il resto sono, per come lavoro io, perdite di tempo. Sicuramente ci
sono metodi di lavorare in cui invece fa una grossa differenza, YMMV.
 
Ciao!

 [...]
 
 
Ciao  Manlio

 Ciao!
 
 
Ciao  Manlio