ARGOMENTO: Certificazione di un modulo presso Tiny

Non dico che la certificazione dei moduli non avesse senso, ma dico che quel codice di certificazione, casualmente, veniva apposto su tutti i moduli rilasciati da Tiny anche se non funzionanti.
Ancora oggi ci sono moduli non funzionanti sulla release attuale che riportano un codice di certificazione.

Io ho parecchie certificazioni in ambito informatico che mi sono state attribuite dopo aver risposto alcune domande su un PC.
Questa certificazione a mio avviso certifica soltanto che ho pagato il ticket per quell'esame, e non la mia competenza

Si tratta di software libero, ovvero uno strumento con il quale tu costruisci le soluzioni per i tuoi clienti.
La certificazione dei moduli non ha molto senso, siccome ciò che conta è avere il maggior numero possibile di funzionalità, anche non funzionanti, così da poter fornire servizi e soluzioni ad un costo competitivo.

Uno modulo non funzionante è comunque meglio di un modulo inesistente.
OpenERP NON è un software che gli utenti possono scaricare, installare ed usare.
E non lo sarà mai.
Così come non lo è SAP...

Unit tests e compagnia sono ormai lo standard in tutti i software seri.
Nel caso di OpenERP un test controlla che dati certi dati di una fattura il totale debba essere X, le tasse Y e così via.
Più tests vengono scritti e migliore è il risultato, siccome questi tests vanno a replicare fedelmente lo operazioni che avrebbe fatto un essere umano sul software.

ok, che della certificazione rilasciata da Tiny sia opportuno fare a meno mi hai convinto.. di fronte all'abbondanza di materiale e ad una curva di apprendimento relativamente lenta un qualsiasi riferimento utile a orientarsi poteva essere appetibile, ma a queste condizioni il gioco non vale la candela (un riferimento inaffidabile e` anche peggio che nessun riferimento).

Per certi versi e` una buona notizia, a prima vista avevo avuto la mezza sensazione che degli sbandierati 300+ moduli quelli sufficientemente affidabili si riducessero a un centinaio.. invece cosi` sono tutti buoni allo stesso modo

Riguardo ai tests quello che intendevo dire e` che se domani rilascio un modulo pos che implementa un errore concettuale (perche` le mie informazioni sul dominio applicativo sono errate o lacunose) e copre solo il 10% delle situazioni che si possono verificare utili, i miei tests di unita` riprodurranno lo stesso errore concettuale e verificheranno solo l'implementazione del 10% coperto dal modulo. Dal fatto che tutti i tests sono eseguiti con successo non vengo a sapere molto (e` un'informazione fondamentale, ma non e` come avere una certificazione affidabile o, in modo piu` comunitario, 5 stellette su 5 attribuite da centinaia di altri sviluppatori).

ric ha scritto:
Beh, in realtà i moduli sono ormai più di 700
Quel dato è poco aggiornato.
La qualità del codice man mano aumenta, ma è inevitabile che di questi 700, una buona parte possa essere obsoleta o non testata.

Quando devo affrontare un'implementazione per un cliente, solitamente chiedo in giro quali moduli coprono quella determinata funzionalità, li scarico, li installo...e poi inizio a correggere i bachi

Ma è così con tutti gli altri software che utilizzo.

I tests servono per controllare che il risultato sia quello atteso.
Se le procedure sono scritte male ma il risultato è corretto i tests non possono saperlo.

Riguardo alle procedure, all'interno della community di openerp ci sono vari gruppi di esperti e relative mailing lists.
Ogni volta che devo sviluppare una nuova funzionalità sulla base delle richieste del cliente, tendo sempre prima a chiedere consiglio su queste mailing lists, così da capire se la strada che ho in mente è corretta o meno.

Mi piace! Ma ehm, lo ammetto, da "buon" (proprio eh) agile developer non ho scritto unit test nei moduli. Avresti un modulo ben scritto da indicarmi come modello di scrittura dei test? ... o anche della documentazione, delle linee guida, qualcosa.

dovresti trovare tutto qui:

openerp.camptocamp.com/index.php?option=...61&Itemid=66&lang=en