Newsgroup: it.lavoro.informatica
Titolo: Linus Torvalds, il creatore di Linux, non fa uso di un debugger.

Sappiatelo.
 
 

 Sappiatelo.
 
	bene, ora lo sappiamo. E allora?
 
-- 
L'importante non e' perdere, ma partecipare

 Sappiatelo.
 
Tu pero` usalo.
 
-- 
4ndre4
"The use of COBOL cripples the mind; its teaching should, therefore, be 
regarded as a criminal offense." (E. Dijkstra)
"Ora, questo "Delta11" non è nulla di più di uno scemo del villaggio" - 
(L'Accalappiafasci)


 
Buon per lui,senza non potrei programmare
Evidentemente non sono al suo livello
 

 
 
 
lo credo bene.
 
 
Prova a individuare un bug in una classe java con centinaia di
righe di codice, per non dire qualche migliaio, (e già questo presuppone aver trovato la classe java che ha il bug...), magari con due o 
tre nested loops, senza fare il debug.
Non dico sia impossibile, ma in buona parte dei casi ti tira scemo.
 
Mi sembra che tu programmi in C#, e non in java, ma sarà lo stesso
discorso.
 
 
Tra l'altro io, negli ultimi anni, avendo lavorato su progetti
la cui parte di front-end è sviluppata con framework javascript,
quali jquery o extjs, e anche un po' prototype, ho usato parecchio
anche i browser debugging tools per debuggare il codice js, e in
diversi casi è stata direi una necessità. 
 


Java e C# se posso non li voglio neanche vedere.
Uso C++ e C
 
 


Si vede che c'ha dietro quelli che gli correggono gli errori al posto suo...
 
 

Bisogna imparare a scrivere il codice (il che vuol dire che classi da centinaia e centinaia di righe non sono progettate corettamente) e sopratutto a *testarlo*. Con una buona suite di unit test, il debugger quasi te lo dimentichi.

 quali jquery
 
Una volta per tutte: jquery non e' un framework.

 Bisogna imparare a scrivere il codice (il che vuol dire che classi da centinaia e centinaia di righe non sono progettate corettamente) e sopratutto a *testarlo*. Con una buona suite di unit test, il debugger quasi te lo dimentichi.
 
Su icod trovi lunghe discussioni tra me e reppie, committer FreeBSD, sulla possibilità di avere una coverage decente su software a bassissimo livello.
Per farla breve, è un casino, perchè ti trovi a mockare sistemi estremamente complessi (la VM, lo scheduler, il FS), oppure ad avere una suite lenta ed estremamente complessa, non ultimo nel deploy - un sistema operativo crasha, si blocca, va in hang, difficile sollevi l'eccezioncina carina e gentile.
A me spiace che Torvalds abbia regolarmente di queste uscite, ma credo sia il personaggio. Tra l'altro non penso ne abbia bisogno per dimostrare le sue capacità, stava zitto faceva una figura migliore.
 
  ngw
 
p.s. Anni più tardi hanno implementato questo 
https://wiki.freebsd.org/TestSuite
 - non mi pare ci sia nulla del genere per Linux

 loops, senza fare il debug.
 
il debugger in questi casi non serve a una ceppa. o meglio, lo usi per 
uno scopo dignitosissimo ma che non è il suo. 
 
il debugger è molto utile per analizzare il codice malfunzionante dopo 
che hai riprodotto il bug, tu invece lo usi per cercare step-by-step il 
codice malfunzionante in una condizione praticamente simile al gioco di 
mosca cieca. ovvero per un lavoro che se il codice fosse stato scritto in 
modo corretto e testabile non avresti nemmeno avuto necessità di farlo. 


E quindi?
Non che faccia una gran differenza, 
http://www.html.it/articoli/framework-a-confronto-jquery-mootools-prototype-1/
 


Cioe' non vedi differenza tra framework e library?
 
 

 E quindi?
 
Quindi jQuery non e` un framework. Se poi uno non sa la differenza tra framework e library, e` un altro discorso.


Il cazzone non sa che si possono fare tutti i test che si vuole (io uso 
xp) ma se un test fallisce vai a cercare il problema senza un debugger
E' una attivita molto divertente
La batteria di test puo dire (se va bene) dove si è verificato l'errore 
(una precondizione/postcondizione/invariante/crash) ma non la causa.
Il cazzone probabilmente  crede gli altri (tutti gli altri,tranne lui 
ovviamente) non sappiano programmare e non sanno cosa sia una batteria 
di test.
Non gli rispondo direttamente in quanto è nel killfile,scusa l'intrusione.
 

 Non gli rispondo direttamente in quanto è nel killfile,scusa l'intrusione.
 
Beh, dai, dipende: con linguaggi ad alto livello io non apro un debugger da 500 anni circa, e faccio tutto con i test delle unità. Che non ti dicano la causa per cui un test fallisce è un'affermazione un po' strana, non mi sono mai trovato in quella situazione, normalmente invece ho perfettamente idea di cosa sia andato storto.
Da dire anche che credo che Ruby con Rspec/Cucumber abbia i migliori framework sul mercato, sto usando Elixir in questo momento e sto smadonnando in sloveno perchè mi pare che la suite di test che ho scritto copra tipo il 2% del codice.
Mi riferivo principalmente all'ambito in cui opera Torvalds (che proprio non è il mio) che forse è quello dove lo unit testing è meno effettivo in assoluto.
 
 
  ngw


Allora o sono programmi banali, o le singole classi sono testate bene 
(unit test per ogni classe ma occorre le persone che lo facciano).
Io sono solo a sviluppare,quando mi capita,ed uso principalmente C e C++.
Non ho certo il tempo per ogni classe (in C++) di fare una unit test 
(triplicherei il tempo per il prodotto finito).
 
Per finire contraddico la tua affermazione,una unit test puo dire dove 
e' fallito (se va bene),ma non il perchè
La causa sta al debugger umano trovarla, magari dall' errore si puo fare 
una idea del problema,ma comunque sta sempre a lui risolvere.
 
L'ultimo grosso debug l'ho fatto 6 mesi fa circa,un grosso applicativo 
(un server di rete) scritto in C da gente che dovrebbe andare a zappare 
invece che scrivere codice.
1 Mese per trovare il baco, e posso ringraziare nemiver (debugger 
grafico per C/C++  sotto linux).
Senza di lui non so quanto tempo ci avrei messo.
 
Nell'ambito dove opera Torvald esiste kgdb fatto apposta per debug lato 
kernel.
Sulle unit test sono d'accordo con te,a quei livelli hanno poco significato.
 
Su ruby ed i suoi framework non dico niente,Ruby lo conosco poco (molto 
poco) e i suoi framework per niente.
 
Buona fortuna con la tua suite di test (il restante 98% da fare).
 
 
 
 

 test (triplicherei il tempo per il prodotto finito).
 
il costo è un argomento su cui si può discutere. ci può stare di non 
riuscire ad applicare a pieno la tdd, ma ciò non toglie che si possa 
applicare in modo ragionevole e, soprattutto, che ci si imponga di 
scrivere il codice seguendo le regole di testabilità. 


No, dico solo che nell'economia del discorso, non ho trovato che tale 
differenza abbia influito, esattamente come nell'articolo che ti ho citato.
Da cui la mia domanda "E quindi?", ovvero a che scopo la puntualizzazione?
kojak parlava di debug della ui, indipendentemente dal framework o 
libreria utilizzata dal codice, almeno cosi' mi e' sembrato.


Ripeto, cosa comporta questa puntigliosa distizione?
Ovvero, nell'economia del discorso di kojac, che parlava di debug, che 
peso poteva avere la differenza tra framework e library?
Se cicap voleva spiegare questo, ha perso una buona occasione di rendere 
la sua sapienza fruibile da parte della comunita'.
Se invece voleva semplicemente sfoggiarla, la sua sapienza, non vedo 
come un asserto perentorio e privo delle necessarie dimostrazioni o 
spiegazioni, possa aver arricchito il discorso.
 

 No, dico solo che nell'economia del discorso
 
Ah ecco.
 
Visto che continua a perpetuare "l'imprecisione", ho trovato doveroso 
correggerlo. Sai, se per caso gli capitasse di fare un colloquio di 
lavoro dove si parla di jquery, potrebbe anche andargli.

 Non gli rispondo direttamente
 
Oh, si`, che lo fai, ma ovviamente non ti piace leggere le risposte che ti smentiscono, idiota incompetente.
 

 Beh, dai, dipende: con linguaggi ad alto livello io non apro un debugger da 500 anni circa, e faccio tutto con i test delle unità. 
 
Ma tu perdi anche tempo a rispondergli? E` solo uno dei tanti deficienti che su questo gruppo apre bocca tanto per farlo.

 dimostrare le sue capacità, stava zitto faceva una figura migliore
 
Per correttezza va detto che parlava esclusivamente di kernel debbugger:
 
http://linuxmafia.com/faq/Kernel/linus-im-a-bastard-speech.html
 
 
-- 
Soprano

 Per finire contraddico la tua affermazione
 
Ma cosa vuoi contraddire? Non usi gli unit test, non sai cosa sono, e li critichi? Parla quando sai! I-D-I-O-T-A.
 

 peso poteva avere la differenza tra framework e library?
 
Che vi possa essere alcunche` di interessante in quel che scrive kojak lo escludo a priori. Il punto e` che se uno ripete continuamente che jQuery e` un framework, dopo la decima volta ha senso puntualizzarlo.

 una idea del problema,ma comunque sta sempre a lui risolvere.
 
No, mi spiace. I casi sono due, o il tuo software solleva le eccezioni meno descrittive del pianeta, oppure la tua suite di test è di un'inutilità assoluta e completa.
Qualunque framework di test che ho mai usato (quindi Java, Clojure, Erlang, Python, Elixir e Ruby li puoi tranquillamente includere) ti da feedback su expectation, risultato ottenuto, stacktrace, environment, eccezione sollevata e *riga del codice*.
Fatico a credere che C++ (che non conosco) abbia un ambiente così pessimo da non permettere TDD. Se è così, peccato, fortuna che uso altro.
 
  ngw


Ha fatto un discorso molto diverso in effetti. Oltre che fatto, se non leggo male, 16 anni e rotti fa.
 
  ngw

 Sappiatelo.
 
  Linus Torvalds *è* il debugger.
 
  Più seriamente, anni fa avevo letto un'altra intervista in cui
dichiarava che ormai lui scrive molto poco codice rispetto ai primi
dieci anni, che adesso il suo ruolo primario è di coordinatore e di
prendere le decisioni sull'indirizzamento dello sviluppo.
 
 
  Ciao,
 
 
-- 
Alessandro Selli 
http://alessandro.route-add.net
 
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.

 
 
 
beh ma che discorsi, è ovvio.
Lo unit test mica ti risolve il bug, lo unit test è un modo per
avere maggiori garanzie che il codice funzioni.
 
 
Poi un altro discorso è dire che il debug è uno strumento comodo
per scovare il punto da sistemare, e su questo sono assolutamente
d'accordo.


 
 
già, ma come si dice dalle mie parti, SE mia nonna avesse le ruote
sarebbe un carro.
Tu puoi andare avanti all'infinito a dire questo, e io posso
andare avanti all'infinito a dire che hai ragione, ma la realtà
è fatta di fatti concreti, non di SE.
 
 
E i fatti concreti, in questo caso, sono dover trovare un bug
in un punto dell'applicativo che coinvolge N classi, alcune
delle quali molto complesse, e ripeto, in questi casi senza
un debugger sarei molto in difficoltà. Punto.
 
 
 
p.s.
una notazione: dati i toni della nostra ultima discussione
(dei quali qualche colpa è anche mia, in effetti),
ti dico subito che non ho alcuna voglia che si crei di nuovo
una situazione analoga, quindi se intendi discutere civilmente
anch'io intendo farlo, altrimenti chiudo subito il confronto.
 
Come dice il proverbio, prevenire è meglio che curare.

 Se il test fallisce puoi benissimo andare a vedere i logs[...]
 
Ma quali log? Le assert in uno unit test ti indicano la condizione 
precisa che fa fallire i test. Non serve andare a sbirciare nessun log.
 
-- 
4ndre4
"The use of COBOL cripples the mind; its teaching should, therefore, be 
regarded as a criminal offense." (E. Dijkstra)
"Ora, questo "Delta11" non è nulla di più di uno scemo del villaggio" - 
(L'Accalappiafasci)

 scovare e risolvere il bug?
 
Il corretto comportamento di una classe di stabilisce con uno unit test 
(meglio se in TDD), *NON* serve il debugger per quello. Debuggare il 
codice serve per lo piu` a scovare errori di integrazione tra la tua 
classe e il resto del mondo. E anche quello si puo` testare con gli 
integration tests e i system tests. Come detto: con delle buone suite di 
test, il debugger quasi te lo dimentichi. Quando scrivi una classe, devi 
essere piu` che sicuro che cio` che il comportamento che hai 
implementato e` corretto e per questo si usano gli unit test. Se si 
segue un approccio TDD, poi, e` altamente improbabile si arrivi ad avere 
classe da centinaia di migliaia di righe. Qui si sta dicendo che, 
imparando a scrivere codice non di merda e ben testato, si evita di 
usare il debugger, e tu rispondi "no no, il debugger serve, sapessi su 
quanto codice di merda e non testato l'ho usato!"



Certo certo, ha parlato quello che lo fa per lavoro ed è in cima alla 
lista. Ma col caldo lassù non schiatta nessuno?
 

 Come dice il proverbio, prevenire è meglio che curare.
 
ma vedi di crescere, pistolino. se vuoi discutere con gli adulti comincia 
a levarti quell'aria da verginella violata. ora mette anche le mani 
avanti con il suo monito di civiltà, lui che l'altra volta si stava per 
beccare una denuncia... vahia vahia.


chi è l'op? ciccio? allora è normale.

 prevalentemente
 
Cioe' vengono scritti da altri??


 
Niente da dire sulle unit test
Ma prova a fare un parsing di un linguaggio o un monitor di rete o una 
serie di classi C++ per accedere ai db
E vai senza debugger
Poi mi dici qualcosa.
 


 
 
Anche il C++ d'ha lo stack trace oppure puoi debuggare su una immagine 
post morten
Devi comunque avere un debugger altrimenti normalmente non lo hai 
(occorrono delle routine che dipendono dall'OS per averlo).
 
 


Appunto, la unit test ti dice dove e' andato in errore
L;eventuale assert fallita,ma non la causa logica.
 
 
assert(p);
 
 
se p e' un puntatore nullo assert va in errore e ti dice dove (file 
sorgente  e numero di riga) e la causa (il puntatore nullo che non 
doveva esserlo).
Ora per quale motivo il puntatore era nullo l'assert non te l'ho puo dire
Sta al debugger umano trovare il motivo.
 
 
Un altro motivo e senza crash
 
pp < infile > outfile
diff outfile file_che_doveva_essere_prodotto_dato_infile_in_input
 
 
diff ti dice che se il file prodotto e' corretto o no
Se non lo fosse non ti puo dire il perchè
 
 
 
Questo e' il significato che intendevo
 
 

 ai db E vai senza debugger Poi mi dici qualcosa.
 
ovvero il debugger a te è di ausilio per la scrittura del codice? hai 
bisogno di verificare passo passo il comportamento del codice che tu 
stesso scrivi? 

 stesso scrivi?
 
Io sinceramente ci ho letto un'altra cosa e, in certa misura, mi ci sono riconosciuto.
Situazione: scrivo del codice per leggere dati da campo; con il mockup scritto secondo le specifiche funziona correttamente; mi attacco al bus di campo (Siemens Step7) e non va più una mazza. Mi accorgo, grazie al debugger, che il problema sta nelle word scambiate: mi vengono ritornate coi bytes girati! mentra da supervisore a campo vengono passate big endian, da campo a supervisore arrivano little endian. Segnalo la cosa a chi ha scritto il programma per PLC, che aggiunge una funziella per girare i bytes prima dell'invio, e l'incidente si conclude.
OK, non stiamo parlando rigorosamente di unit test. Scrivere software, però, significa spesso integrare librerie scritte da altri (e ne ho trovate diverse bacate) o dipendere da situazioni che possono non rivelarsi matematicamente certe. In questo caso il debugger (e, nel caso citato, il breakpoint condizionale) aiuta.
 
Ciao!
Luca


cioé le attività che sto svolgendo in questo periodo 
non sempre richiedono la scrittura di unit tests.
 
Sto lavorando prevalentemente sul front-end, e anche i
controller spesso vengono scritti in groovy anziché
in java.
 
Noi dobbiamo garantire una certa percentuale di coverage
del codice java, e il successo degli unit tests, 
che sono stati scritti per testare i servizi. 
 
Questo significa che gli unit tests dobbiamo scriverli solamente 
se mettiamo mano al codice java; se apportiamo modifiche ai 
servizi dobbiamo poi assicurarci che i tests siano ok, 
e nel caso fare le modifiche opportune.
Quindi, non sempre le attività che svolgo richiedono la scrittura
di unit tests.
 
 
Invece altri contesti richiedono di dedicare più tempo a scrivere
i tests. Tutto qui. 
 
 

 
 
 
Io rispondo semplicemente in base a quello che ho visto nei miei
8 anni di esperienza, e siccome spesso sono stato inserito in
progetti già avviati da anni, con le classi scritte in un certo
modo, essendo impensabile riscrivere il codice daccapo ho
usato gli strumenti più idonei.
 
Sono d'accordo sul codice di merda, che spesso mi fa tirare
madonne se è per questo, ma, ripeto, possiamo ripetere che
bisognava farlo meglio fin che vogliamo, ma la sostanza non cambia.

 beccare una denuncia... vahia vahia.
....splendido esempio di slang Pratese
 

 serie di classi C++ per accedere ai db
 
Che il C++ ti obblighi ad usare un debugger non dice niente sulla 
indispensabilita` di un debugger. Se usi un linguaggio che ti complica 
la vita e` un problema tuo. Ma in C++ si puo` fare benissimo unit 
testing, per cui, se c'e` qualche problema, e` un problema di competenza 
tua. Compilatori e monitor di rete io ne ho scritti e lo unit testing si 
applica ugualmente a quei progetti. Il debugger non e` un tool di 
costruzione del codice.


altri (e ne ho trovate diverse bacate) o dipendere da situazioni che possono non rivelarsi matematicamente certe.
 
Lo unit test, con le librerie "scritte da altri", non ha NIENTE a che 
vedere. Il problema e` che voi, gente, e per vostra stessa ammissione, 
continuate a parlare e sparlare di unit test senza sapere cosa sia, 
senza sapere come si implementi, senza sapere come vadano configurate le 
dipendenze. Lo unit test serve a testare il funzionamento della *TUA* 
classe, non dell'interazione della tua classe col mondo esterno.


 Io rispondo semplicemente in base a quello che ho visto
 
...e come sempre ti sei perso un pezzo di discussione.


 
 
 
beh io ti posso fare un esempio analogo di test in java.
 
Se tu, nel tuo test, devi testare che un oggetto object non sia
null, puoi fare (con junit):
 
assertNotNull(object)
 
e volendo puoi anche utilizzare un metodo assert che, in caso di
fallimento, ti dà un messaggio specifico che decidi tu.
 
 
Ma se esegui il test non vedi solo il messaggio che ti dice che è
fallito, e quindi che object è null: puoi seguire tutto lo
stack-trace e da lì puoi cercare di capire per quale motivo si è
verificato l'errore, esattamente come avviene se il codice viene
eseguito dall'applicativo, e non dal test.
Io questo sto dicendo.
 
Quando parlo di applicativo, intendo una web-app, ciò che è il
mio ambito di lavoro.
 


 
 
già, ma siccome eri tu stato a iniziare per primo, dicendo
 
"puoi immaginarti da solo quanto me ne frega del fatto che non mi segui. 
manco fossi quel disgraziato che ti da lavoro, e ti paga pure pensa un 
po'." 
 
anche io potevo denunciare te per diffamazione, quindi io dico
che nella merda ci finivi prima tu di me.
Quindi non credo ti convenga insistere più di tanto su questa storia.


In C/C++ idem,nel debugger
 


Lo sviluppo e' una scienza molto complessa
Non si fa solo con le unit test
 


 
Il debugger fa parte delgli strumenti di sviluppo cosi come l'editor,il 
compilatore e la shell per gli unit test e test completi.
In pratica e'un ide a parte la shell
Visual C++ di MS  e' un ottimo ide,un po meno il compilatore (non e' 
proprio aderente agli std quando ha che fare con i template).
Ma normalmente compilo anche con g++ sotto linux.
 
 


caro cogiacchino dei miei stivali, ti ho già detto che se vuoi dibattere 
coi grandi devi smettarla di atteggiarti ogni volta a verginella violata. 
inutile dirti ciò che urta la tua suscettibilità immatura non è illecito 
(diffamazione? rotfl) e frasi come quella rientrano in quella che si 
chiama dialettica, o retorica, vedi le figure retoriche. a differenza 
delle tue sbroccate che ben poco hanno di civile, caro il mio 
cogiacchino. non ti piace la piega personalizzata che prendono le 
discussioni? mi dispiace, ma sei te medesimo che sottoponi i tuoi panni 
sporchi al giudizio della community. riflettici, se ti riesce.
 
 

 Chiamala come vuoi
 
Ma cosa dici! Non puoi confondere unit test con altri tipi di test. 
Anche perche' dovrebbero usare approcci diversi, essere eseguiti in fasi 
diverse del progetto, usare strumenti diversi.
 
Semplicemente tu non hai la benche' minima idea di come si scrivano test 
automatici.

 (diffamazione? rotfl) e frasi come quella rientrano in quella che si 
CUT
 
Ma se lui fa leggere al suo capo quello che hai scritto, il suo
capo ti potrebbe fare un culo grosso come una casa colonica.
 
 
 

 capo ti potrebbe fare un culo grosso come una casa colonica.
 
Credici.

 citato, il breakpoint condizionale) aiuta.
 
si ma che c'azzecca? anche nel caso di un bug di una libreria terze parti 
parti sempre da un test che fallisce, no? oppure passi il tuo tempo a 
debuggare codice che non sai se ha bisogno di essere debuggato?
 


ah sì?
lavora alle dipendenze di pablo escobar gaviria e non lo sapevo?
 
 

 diverse del progetto, usare strumenti diversi.
 
E sopratutto scritti da persone diverse.
 
-- 
Soprano


Beh no perche'? Integration test, unit test, end-to-end test vengono 
scritti dallo stesso sviluppatore.
Con il TDD parti proprio da un end-to-end test, che guida lo sviluppo.
 
Quello che intendevo, e mi sono espresso male, e' che vengono eseguiti 
in diverse fasi della build. Ovviamente non puoi eseguire un end-to-end 
test o un integration test verso il database ogni volta che modifichi un 
file.
 


Per me è sempre meglio che integration test a alto livello siano scritti 
da qualcuno che non abbia scritto il codice (in particolare, dai testing 
team, che stanno lì apposta) in quanto il programmatore continuerà a 
seguire il proprio processo logico con il quale ha sviluppato il codice 
anche nella scrittura del test, rischiando di non far emergere difetti di 
programmazione legati al quel processo.
 
-- 
Soprano

 vedere. 
 
Infatti io parlavo di utilità del debugger. Affermare che è totalmente inutile è una sciocchezza.
 
-- 
Ciao!
Luca

 si ma che c'azzecca? 
 
Anche a te devo la stessa spiegazione. Scorrendo molto velocemente il thread (enorme) magari ho frainteso, ma mi sembra di aver letto cose del tipo "non serve il debugger, l'unit testing risolve tutto!". Può essere, ripeto, che abbia frainteso io; in ogni caso penso che affermare "il debugger è totalmente inutile" (un po' ciò che sottendeva il post inizio del thread) sia una clamorosa sciocchezza.
 
-- 
Ciao!
Luca


Eh la miseria, la corte si riunisce in che orari?
 
 


Magari sono io che ho frainteso, per le stesse ragioni che hai addotto tu.
Pero', rilevo che cio' che e' stato rimarcato, e' che il debugger non 
sia utile per individuare i bug, operazione a cui sono preposti gli 
unit-test, ma per risalire al codice errato individuato da un certo 
unit-test.
Va da se' che se le unit sono sufficientemente circoscritte e se 
l'insieme di unit sotto test sono sufficientemente articolate, 
probabilmente non sara' necessario ricorrere al debugger.

 ha scritto:

Alle 22.30, da Gino er tricheco :-D
 
 
 

 probabilmente non sara' necessario ricorrere al debugger.
 
Vero questo, allora ho proprio frainteso io.
Io non ho mai usato il debugger, a dispetto del nome, per scovare problemi di logica nel software che ho scritto - in realtà qualche volta, preso da disperazione, l'ho fatto, ma ero giovane e stolto - . Come spiegavo nell'esempio, la mia idea è: c'è una situazione inattesa, so che la logica implementata è corretta, vediamo che diavolo sta succedendo. In questo ambito, il debugger è di grosso aiuto - nel mio caso, i breakpoint condizionali mi han fatto capire che arrivavano dati fuori dai limiti previsti.
 
-- 
Ciao!
Luca


Io non faccio di professione il tester
I test me li scrivo da solo tutto a mano quando servono (script di shell)
E non sarebbe neanche un compito mio.
 


Mi viene il dubbio che tu scriva queste cretinate con l'unico scopo di 
trollare. Non puoi essere cosi' perfettamente ridicolo.
 
 
 

 programmazione legati al quel processo.
 
Beh questo è un po' discutibile per me, nel senso che va bene che la validazione venga dall'esterno (ad esempio con gherkin 
https://github.com/cucumber/cucumber/wiki/Gherkin
), ma poi quasi tutti i tipi di test sono principalmente strumenti di sviluppo. 
È abbastanza raro che un regressione sia talmente macroscopica da far fallire una specifica in toto, normalmente si tratta di una serie di condizioni molto molto strette che l'acceptance test non trova praticamente mai, e specialmente quando si tratta di integration test il maggior vantaggio che si ha è la capacità di gestire l'interfaccia tra sottosistemi, che tipicamente esce da questo processo drammaticamente migliorata (un conto è pensarli i moduli, un conto usarli).
Di contro non mi è mai capitato quello che dici, spesso e volentieri autoconvincersi della correttezza del proprio codice capita ad alto livello e con quantità di codice molto grandi, che non mi capita mai di avere testando le unità e poi le interazioni tra moduli: quando arrivo a testare un intero modulo (libreria, sottosistema, processo, chiamalo come vuoi) questo modulo è già stato modularizzato in parti sufficientemente piccole da dare pochissimo adito ai fraintendimenti di cui parli che invece certamente erano all'ordine del giorno prima che cominciassi a testare il codice come dio comanda, specialmente perchè scrivere i test di parti molto grandi di codice è uno strazio, e un chiaro segnale che qualcosa nel software non va.
 
  ngw


quindi è corretto dire che, come developer, hai l'abitudine di committare 
codice senza averlo mai eseguito e senza averne mai verificato il  
comportamento, ritenendolo compito non tuo?
 
più scrivi e più dimostri che ha ragione chi sostiene che tu i test, e in 
particolare gli unit test, non sai nemmeno dove stanno di casa.
e il bello è che pontifichi sull'inutilità e sull'overhead degli stessi: 
per forza sostieni che triplicano i tempi di sviluppo, visto che non sai 
nemmeno che esiste un intero ecosistema di tecniche e strumenti.

 trollare. Non puoi essere cosi' perfettamente ridicolo.
 
purtroppo temo che, a modo suo, sia assolutamente serio.


Comincio ad avere qualche dubbio: sono troppe le volte in cui le serve 
perfettamente preparate e su un piatto d'argento. Come se sapesse che la 
cosa giusta e' A e invece ti scrive Z.
 
Oppure e' davvero il re dei cretini :)
 


 
Ho scritto che i test me li scrivo da solo.
Tu sarai fortunato, sei magari in una azienda con 30 o piu 
programmatori/tester,ecc..
Una pacchia.
 


sicuramente con quel suo modo di discutere laconico si atteggia ad una 
superiorità impropria rispetto all'argomento di cui discute, ma la sua 
ignoranza è genuina e lo ha dimostrato più volte. secondo me è 
semplicemente un obsoleto che non si è mai aggiornato e per presunzione 
cerca di convincere se stesso e gli altri che non è necessario.
 

 test non li fa proprio.
 
Nella mia esperienza la situazione è molto semplice. Gli unit test vanno 
scritti (io ne scrivo in quantità rilevante) e il grosso della 
prevenzione si fa con quelli. *Ma* è irrealistico pensare di coprire con 
gli unit test il 100% del codice e/o il 100% dei casi.
 
Morale della favola: non riesco a immaginare un processo di produzione 
software moderno che possa essere effettuato completamente senza gli uni 
e senza l'altro.
 
I test di unità sono ovviamente da preferire, ma ci sono dei casi (rari, 
per fortuna) in cui del debugger non si può proprio fare a meno.
 
TheStar