Newsgroup: it.lavoro.informatica
Titolo: Linguaggio più bello.

Mi è venuto in mente questa mattina, mentre mi sbarbavo; lo spunto deriva dalle diatribe COBOL vs. Java vs. resto del mondo.



Per cui, domanda: qual è il linguaggio più bello con cui avete lavorato? e di conserva, quale quello più brutto?



Non sto parlando di caratteristiche tecniche, di efficacia o altro. Sto parlando di una questione puramente emozionale (AKA divertimento).



Inizio io.



Linguaggio più bello. Se la giocano: C++ e Python, con una leggera preferenza per Python.

Linguaggio più brutto. Visual Basic. So che oltre a un linguaggio è un ambiente, però ho sempre mal sopportato l'accrocchio messo in piedi da Microsoft.



-- 

Ciao!

Luca




 Non sto parlando di caratteristiche tecniche, di efficacia o altro. Sto parlando di una questione puramente emozionale (AKA divertimento).

Puramente emozionale, di sicuro lo SmallTalk e' quello che mi ha 

appassionato piu' di ogni altro.

Quello che mi ha fatto bestemmiare di piu' e' il COBOL, non tanto per il 

linguaggio in se, fa dei conti e piu' di tanto non si puo' pretendere, 

ma per la mancanza di un editor che non fosse analogo al notepad (magari 

negli ultimi 20 anni qualcosa e' cambiato, ma io mi fermo la').




 Per cui, domanda: qual è il linguaggio più bello con cui avete lavorato?



Come linguaggio, il migliore è quello / scurrile /  tendente al turpiloquio 







concordo con te, vecchio troll morpher di merda nonché coglione e 

incommensurabile testa di cazzo.





Sempre lui Nato Stanco da 
eternal-september.org




Chiaramente la domanda è soggettiva,comunque ecco qua:



Ok:  C e  C++, per me i due must piu perl (non conosco cosi bene Python 

per giudicarlo ma credo che sia un buon linguaggio)





Ko:   APL e RPG



Orribili..

Il COBOL rispetto a RPG è un must,tanto per fare capire.

APL è un linguaggio a simboli,un po strano,piu un esperimento che altro.

Praticamente un linguaggio write only.













Correzione,la risposta è soggettiva non la domanda.





php e cobol


 parlando di una questione puramente emozionale (AKA divertimento).



Sono banale temo...



PIU' BELLI:

C# e, prima prima, VB6



PIU' BRUTTI:

Visual Object e poi con ENORME distacco C++6



-- 

Al3xI98O

«L'importante non è cadere, ma sapersi rialzare»

«Sono responsabile di ciò che dico, non di quello che capite»


 C# e, prima prima, VB6



Tu sei posseduto dalla microzozz :-D







L'Apl lo vedevo usato in ambito aziendale (cioè non universitario e simili), molti anni fa, per fare calcoli statistici. Credo avesse una buona libreria di funzioni sulle matrici.

I simboletti grafici possono essere un plus od un minus, dipende quanto sono simili ai simboli matematici corrispondenti. 

Il peggior linguaggio usato? Sicuramente il Cobol su mainframe, all'epoca già esistevano i pc ed era veramente un altro mondo. Tanto che VB era una manna al confronto, tra editor potenziato, colori, grafica :-)

Il migliore? Direi Delphi, forse perchè ci faccio le cose più divertenti.


[...]parlando di una questione puramente emozionale (AKA divertimento).



BASIC-8000 Olivetti. Avevo 9-10 anni e mi ci divertivo un mondo.



èèèèè lo dicevo io....orgoglio di papà

IN...CRE...DI...BI...LE!



-- 

Quando la dittatura è un dato di fatto, la rivoluzione diventa un diritto.

(Victor Hugo)



tu sei un troll...di la verità ...a me lo puoi dire!

siete incredibili...cazzo!







scusa... specifico: php il più bello, cobol il più brutto


 [...] Sto parlando di una questione puramente emozionale



domanda complessa... emozionale?... mumble mumble...

Il primo amore, quello che non si scorda mai, senza ombra di dubbio è assembly: si passavano le notti a litigare, ma quando si faceva pace, insieme facevamo di tutto, e si scoprivano pertugi nell'architettura che nessuno tra a amici e conoscenti aveva mai esplorato. Di contorno c'erano le ragazzotte adolescenti basic& pascal, brufolose, con le gambe storte, truccatissime ed appariscenti, uscivano con tutti per colmare la propria insicurezza, ma erano ritrose a concedersi al 100%. E non poteva mancare la ragazza idolo, quella per eccellenza, vista solo in foto, e mai approcciata, Ada :-(

Poi si cresce, si matura, si conosce questa e quella, tante, one night stand, passati gli anni ci si ricorda a malapena il nome ma si preferisce far finta di non ricordare, soprattutto per evitare domande con risposte imbarazzanti :-) E alla fine si decide di metter la testa a partito, ci si sposa, matrimonio poligamo con due sorelle gemelle, ma non monozigotiche, C e C++, è amore maturo, entrambe sono spose fedeli, danno dei bei figli, ma i ricordi delle porcate fatte in giovinezza affiorano e molto spesso spunta la friend with benefit C/C++, che non presenteresti mai ai tuoi amici per quant'è zozza, ma le zozzate che ci fai non hanno eguali. Passano gli anni e  C e C++ sono due spose teteske, diligenti, forti e robuste, ma alle volte hai bisogno della scappatella scacciapensieri, quella che ispira, quella che solo la mistress Matlab può dare, l'unica che con un'occhiolino ti riesce a far montare due gpu senza preliminari in una botta sola :-)



C#



javascript (scritto tutto attaccato e in MINUSCOLO!), una porcheria.




 Non sto parlando di caratteristiche tecniche, di efficacia o altro. Sto parlando di una questione puramente emozionale (AKA divertimento).



Er più: un dialetto proprietario di ML (molto vicino a Standard ML per intenderci), ad uso generale ma anche specializzato per due particolari theorem provers. L'ho usato per verificare tra l'altro il codice di parte di un sistema di trasporto ad alta velocità (tipo TGV) - mai divertito così tanto a risolvere portando a casa bei soldi e con un match problema/linguaggio perfetto.



Il meno divertente: C. Non c'è nulla di divertente nell'audit, verifica, rewrite, integration, blablabla etc. di centinaia di milioni di righe di C scritte con standard qualitativi mooolto lontani dai propri.



sei un grande! direi un vero informatico...come è difficile da trovare 

oggi...con una mente  aperta, senso dell'ironia....e una cultura non 

indifferente...un UOMO.



 Tu sei posseduto dalla microzozz :-D



Questo è poco ma sicuro... Il massimo di allontanamento è quando uso 

MySql o Oracle come db ma... tutto il resto del mio mondo è MS :D



 èèèèè lo dicevo io....orgoglio di papà



Taci, rincoglionito.




assembly



Vero, anche l'Assembly x86 e` stato abbastanza divertente. Meno male che Turbo Assembler e Turbo Debugger distribuiti con il Turbo C mi venivano in soccorso. Devo dire che ho imparato moltissimo dai sorgenti asm della libreria standard C. Una fonte inesauribile di best practices.   


 Per cui, domanda: qual è il linguaggio più bello con cui avete lavorato? e di conserva, quale quello più brutto?



"divertente" lo associo più all'applicazione pratica piuttosto che al

linguaggio. da questo punto di vista i linguaggi che ultimamente trovano

le applicazioni più divertenti sono python, scala, ma anche javacript

con node.



di contro i peggio direi sql, pl/sql e analoghi, 
asp.net
 e più in generale

lo sviluppo web su windows.


 MySql o Oracle come db ma... tutto il resto del mio mondo è MS :D



E devi redimerti... ;-D






 lo sviluppo web su windows.



Infatti sviluppare per il web su server windows è come andare

nella savana africano a caccia di leoni armato solo di una fionda.






 indifferente...un UOMO.



ti ringrazio, ma se per essere veri informatici bastasse scrivere quattro degenerazioni nostalgiche a base sessuale su usenet, ci sarebbero tanti veri informatici quanti account Facebook :-)




ciccio in data domenica, 17/01/2016 ha detto:


eheh, dovrei cambiare (di nuovo) lavoro :P oppure trovarmi un hobby :D



 javascript (scritto tutto attaccato e in MINUSCOLO!), una porcheria.



Come mai?


 Come mai?



Caso mai..






 javascript (scritto tutto attaccato e in MINUSCOLO!), una porcheria.



Giudizio troppo severo. E` una porcheria sotto molti aspetti, ma se si considerano le "good parts" di cui parla Crockford, non e` poi cosi` male.




 e di conserva, quale quello più brutto?



nessuno, sono tutti belli a loro modo



-- 

Soprano






Più belli:

Smalltalk e Objective-C








Migliore: clojure/clojurescript. 



Seriamente, a chi può non piacere una volta che hai avuto il coraggio di tuffarti dentro?



Peggiori: non ho mai digerito SQL e plsql.



Perché MS si è dovuta inventare type script per andarci "sopra" per 

garantire uno sviluppo diciamo decente?

Più js si deve scrivere e debuggare che finisce sui client, più direi 

che mi sembra evidente che js di suo sia una zozzeria per le eccessive 

libertà che concede e quindi per i facilissimi errori di distrazione che 

capita di fare sempre di più al crescere di quanto codice tocca scrivere 

lato client. Tutti begli errori dormienti pronti a manifestarsi in modo 

più o meno chiaro solo runtime.






 libertà che concede 



JavaScript ha dei grossissimi difetti, ma si rimedia adottando delle convenzioni specifiche, concentrandosi sulle "good parts", e sopratutto facendo unit-testing, una pratica purtroppo da molti ancora ignorata. Esistono framework come Jasmine che consentono di coprire gran parte dei potenziali casi di errore. Nella mia azienda, abbiamo un intero team che sviluppa in JavaScript, e grossi problemi non ne incontriamo.




Perché usare framework orientati a js quando si può usare un'alternativa 

che è di fatto un linguaggio migliore (penso sempre a type script citato 

in precedenza) e quindi risolvere la questione a monte?






 in precedenza) e quindi risolvere la questione a monte?



Ma cosa stai dicendo? Cosa c'entra Jasmine, che e` un framework per unit-testing, con TypeScript? 



Mi par chiaro, preferisco avere un linguaggio migliore perché anche 

senza unit test ci imbrocco prima a scrivere il codice che funziona come 

voglio.



perché non risolvi nessuna questione a monte. jasmine è un testing 

framework che si usa anche con typescript.





Quindici anni di Agile e ancora siamo a questo punto?


 voglio.



Da quel che scrivi, si deduce tu non sai ne` cosa e` lo unit testing, ne` cosa e` Jasmine, ne` cosa e` TypeScript e, forse, non sai neanche cos'e` JavaScript :)





Perché te sviluppi in js con unit testing?

Io no, come già scritto sopra. Quindi potendo usare type script mi paro 

il culo direttamente in compilazione invece di scoprire i problemi a 

run-time. Che tradotto vuol dire risolvere il problema a monte.

Mi par chiaro.





I constraint che puoi usare con type script ti risolvono i problemi a 

monte, par facile come concetto.





Da me si, niente unit testing. Non essendoci quello certi problemi si 

risolvono appunto a monte con qualcosa di più decente del js liscio.




 monte, par facile come concetto.



ma gli unit test non si applicano ai problemi che tu intendi risolvere 

con i constraint, altrimenti mi spieghi il massiccio uso nei linguaggi

a tipizzazione forte e statica come java?



i test sono parte del processo, non del linguaggio. anche questo par facile

come concetto.


 risolvono appunto a monte con qualcosa di più decente del js liscio.



Il problema e` che tu non sai cos'e` lo unit testing, e nel 2015 e` molto grave.


 Mi par chiaro.



Mi par chiaro che tu non hai la minima idea di come si sviluppi il codice oggi.





Tu in compenso non sai in che anno siamo :)



-- 

Soprano


 monte, par facile come concetto.



I constraint non ti riparano da bug di regressione. Mi par facile come concetto.






[...]



Sarà perché sei rimasto indietro :D



G.




 Sarà perché sei rimasto indietro :D



Si`, certo, credici.


4ndre4 wrote on 21/01/16 12:13:


Sei sempre così supponente che non solo non ti accorgi delle faccine e di cosa 

era stato quotato, ma neanche ti viene in mente di rileggerti.

Copio-incollo dal tuo precedente messaggio (e te l'aveva già fatto notare 

AleTV): "oggi, anno 2015", ma sai, siamo nel 2016.



Adieu,

Gabriele


 Sei sempre così supponente 



Ma vai a cagare.




Soprano <dor...@PPPchello.PPPat> ha scritto:


ROTFL X-D






 ha scritto:


ROTFL :-X










 Tu in compenso non sai in che anno siamo :)



2015 o 2016 non cambia molto.






 ha scritto:


Certo... Nell'IT un anno è niente, non ci sono novità, non cambia nulla...



:-S








4ndre4 wrote on 21/01/16 13:06:


ROTFL

21 gennaio 2016 è un po' presto per la sbroccata dell'anno, caro "4ndre4"!



x-post e f/u



Gabriele



:-)





Certo che è facile, infatti non li ho tirati fuori io parlando delle 

libertà di js e delle imbragliature di typescript che sono molto utili 

nello sviluppo. Qualcuno ha pensato bene di spostare l'attenzione allo 

unit test che è altra cosa. E se uno la fa ecco che, come già detto due 

o tre volte, avere un linguaggio migliore di certo aiuta.





Tu sviluppi in js via unit test? No, bene.

Manco io, uso type script che è meglio, molto meglio, di niente.

Nel 2016 chi sviluppo non può non farlo via unit testing? Ok, pazienza, 

me ne farò una ragione, magari in ditta chiederò di farti chiamare così 

chiarisci il concetto di quanti nel mondo siano pantaloni non degni di 

scrivere sw. Magari capita che il tempo disponibile lo si metta lato 

funzionalità, magari eh.





Se uno non lo fa, riferito a non fare unit testing.




 Se uno non lo fa, riferito a non fare unit testing.



ma è una stupidaggine dire che un linguaggio "migliore" aiuta a non fare

unit testing. quando scrivi un test non è che vai a verificare se hai scritto

bene il nome di una variabile piuttosto che una funzione. il significato

dei test è quello di verificare il comportamento di una determinata 

porzione di codice, che sia quello atteso e anche che non cambi nelle nuove

revisioni.


 revisioni.



Cosa che si può fare ugualmente eseguendo "unit testing" manuali, come si è sempre  fatto. Cosa tediosa, prona ad errori, anche costosa, certo, ma perfettamente fattibile.

E' di attualità intendere per "unit testing" la scrittura di software che verifica altro software, cosa che crea altri problemi (chi verifica che gli unit test siano correttamente scritti? Gli unit test degli unit test?). 



Hai messo il dito nella piaga. Io ho sempre sostenuto, forse sbagliando, 

che gli unit-test li debba scrivere un terzo. Uno che non conosce il 

codice da testare se non per la sua interfaccia pubblica. Per il 

semplice fatto che se ho commesso un errore concettuale nel codice da 

testare, non vedo perche' non dovrei commettere lo stesso errore anche 

nel codice del test.


 nel codice del test.



Amen



Francesco


Il giorno venerdì 22 gennaio 2016 08:51:05 UTC+1, Dr.UgoGagliardelli ha scritto:


Giusto. D'altra parte se il metodo o funzione non è  semplice semplice lo unit test può essere un programma di tutto rispetto, soggetto pari pari ad errori.

Farli fare ad un terzo? Forse, ma è sicuramente un costo in più, ed inoltre questo terzo deve essere particolarmente affidabile, sennò siamo daccapo.

Personalmente vedo bene unit testing per sgrossare casistiche abbastanza semplici, standard. Ma poi un test più approfondito lo deve sempre fare un tizio in carne ed ossa.


  Ma poi un test più approfondito lo deve sempre fare un tizio in carne 

ed ossa.

Pero' diventa un monkey-tes!

:-)


 :-)



Ni, se ti concentri su casistiche più complesse, che richiederebbero molto codice per gli unit test.

Oppure ti concentri su test di integrazione o di sistema, a più alto livello.


 E' di attualità intendere per "unit testing" la scrittura di software che verifica altro software, cosa che crea altri problemi (chi verifica che gli unit test siano correttamente scritti? Gli unit test degli unit test?).



normalmente i test case non contengono logica, si limitano a fornire i

dati in input (parametri, righe sul db, mock dei collaboratori, etc...) 

e verificare con degli assert i risultati in output. ragionevolmente non

hanno bisogno di essere a loro volta testati.



possono essere scritti in maniera non corretta? certo, ma a quel punto

è un problema che esula dal compito dei test: se lo sviluppatore ha 

introdotto un bug nel codice e contemporaneamente anche sviluppato 

il test case che lo verifica, vuol dire che non è sbagliato il codice ma

sono sbagliate le specifiche.


 sono sbagliate le specifiche.



Cioè? Sono sbagliate od incomplete le specifiche del test, oltre al codice del test? Chiaro, è possibile anche questo.

Si tratta sempre di software aggiuntivo, prono ad errori di vari tipi come tutti i software.


 hanno bisogno di essere a loro volta testati.

Verissimo, ma in molti casi, e' necessario utilizzare un mock che a 

volte ha complessita' analoghe al sorgente da testare.





Diobono, ho detto che un linguaggio migliore aiuta a non fare le cazzate 

che si possono fare con uno peggiore. Gli unit testing li avete tirati 

fuori voi.






Eh, detta cosi' sembra farina del sacco del compianto Massimo Catalano!

:-)


No hai scritto che typescript ti risparmia la fatica di scrivere unit test. 

Tutta questa discussione, tra debug che soppianterebbe un unit test e il linguaggio migliore che non lo richiede, é piuttosto penosa, e sinceramente vi consiglieri di comprare e studiare dei buoni libri per iniziare a capire di cosa si sta parlando.




"

Da me si, niente unit testing. Non essendoci quello certi problemi si 

risolvono appunto a monte con qualcosa di più decente del js liscio.

"



Per i buoni libri, che buoni libri?





Ennesima cagata che fa capire che tu non sai nulla di testing. Il tempo tolto ai test lo paghi dieci volte nella correzione di bug vecchi e nuovi. Anche le nuove funzionalita' potrebbero soffrire a causa del codice  stagnante, ovvero non soggeto ai refactory dovuti.



Vai su Amazon, puoi iniziare da un paio come "Clean code" e "Growing object oriented software, guided by tests".





Ma per cortesia che partendo da zero per andare a regime ci vogliono 

mesi su progetti che non hanno nulla di testing dietro.

Giro anche il tuo contatto ai piani alti così si fan due risate e puoi 

venir li a far vedere quanto tempo si risparmia...




 " **ragionevolmente** non hanno bisogno di essere a loro volta testati". Allo stesso modo si potrebbe dire che *ragionevolmente* una determinata funzione/metodo originario (cioè del software da testare) non ha bisogno di essere testato. Perchè no?



perché in realtà non è vero che le test suite non siano a loro volta testate.

ci sono strumenti, come ad esempio cobertura in java, che forniscono

metriche per misurare la qualità dei tuoi test. 

viceversa nel tuo metodo "manuale" chi/cosa ti garantisce che il 

programmatore abbia condotto i test in modo esaustivo, o che non abbia

proprio fatto finta di farli?


Risparmiati la fatica, non ho alcuna intenzione di lavorare con persone ottuse.


 venir li a far vedere quanto tempo si risparmia...



http://i.imgur.com/2VhtNNY.png



 proprio fatto finta di farli?



Non vedo differenze, la falsificazione (o l'errore) ci può essere anche nel presentare i risultati dello unit test, a meno di non entrare nel merito del codice. In un test manuale, se non mi fido del programmatore, eseguo i test assieme a lui, oppure in autonomia.




Anche se pagano molto bene?





Io me lo immagino così invece:



http://tinyurl.com/jbwxmkd







Eccoci arrivati: questo suona come "io c'è l'ho più lungo". Un esercizio stupido tra l'altro, perché non hai informazioni sulla mia busta paga.



Non mi interessa discutere con persone così, e l'avevo intuito un paio di post fa. Ora ne ho la certezza.




Sopravviverò.




 Non vedo differenze, la falsificazione (o l'errore) ci può essere anche nel presentare i risultati dello unit test, a meno di non entrare nel merito del codice. 



ma non credo proprio, guarda.

non funziona che il programmatore scrive il test, lo esegue e poi presenta 

i risultati dicendo "ho fatto". col cazzo. i test si scrivono e si 

committano nel progetto, poi ci pensano tool come jenkins o sonarqube ad

eseguirli ed analizzare i risultati. 

se provi a barare, tutti vedono le tue carte false. il tuo test farlocco

è lì in una commit con tanto di firma in calce. sicuro di non vedere

differenze?


 differenze?



Se non vai a vedere di persona il codice del test non sarai mai sicuro al 100% se è esatto/completo/farlocco oppure no, nonostante l'aiuto dei tools.

Comunque in breve gli unit test, in quanto software ad hoc che testa altro software, sono utili in tante occasioni, ma non sono immuni da problemi, come tutti i software. 

Tornando al caso specifico, scrivere codice e poi raddoppiare con gli unit test in un linguaggio come Javascript... bè, veramente tanti auguri.


Si i test devono essere scritti con tutti i crismi del caso, altrimenti servono a poco. 

Per questo dico che è il caso vi studiate qualche buon libro sull'argomento invece di continuare a scrivere stupidaggini.


 o tre volte, avere un linguaggio migliore di certo aiuta.



che l'argomento l'abbia tirato in ballo qualcun altro non toglie che tu

abbia scritto:



"Da me si, niente unit testing. Non essendoci quello certi problemi si 

risolvono appunto a monte con qualcosa di più decente del js liscio."



il che è una stupidaggine. non mi riferisco al fatto che non fate unit

test (seguirete altre metodologie, spero) ma alle motivazioni, che denotano

una preoccupante supponenza tecnica. come dire che siccome utilizzate un

linguaggio compilato vi ritenete al riparo da bug e software regression, 

dato che la ragion d'essere degli unit test è scovare questi.




 Comunque in breve gli unit test, in quanto software ad hoc che testa altro software, sono utili in tante occasioni, ma non sono immuni da problemi, come tutti i software. 



si potrebbe discutere serenamente di quanto un metodo sia perfettibile,

se non fosse che lo confronti con il nulla. perché quello che tu descrivi

non è un metodo per testare il software.





Non e' che stai parlando di "stub"?


 Sbagliato, era una domanda.



Era una domanda del cazzo, totalmente inutile per il contesto e unicamente volta a farci capire che tu saresti ben pagato.


 Non e' che stai parlando di "stub"?



no penso parli proprio dei mocked methods cioè dei metodi/oggetti utilizzati

all'interno del metodo da testare e che devono essere simulati. 

classico esempio quando si testa un manager vengono iniettati dei finti

dao che ovviamente devono simulare il comportamento secondo lo schema del

test. 


 non è un metodo per testare il software.



Vero, infatti basta che "i test case (*) ragionevolmente non hanno bisogno di essere a loro volta testati". Questo è un metodo obiettivo e senza fallo :-) 



(*) ed, aggiungo, ovviamente mock, stub, e tutti gli indispensabili collaterali fatti apposta ed unicamente per i test.


Se usi librerie di mocking non vedo il problema visto che si sta giusto cercando di testare come l'oggetto testato comunica con la sua dipendenza (di cui gli si fornisce un mock).



Io a dire il vero ho sempre trovato stupido testare con mock la classica architettura service,dao. In quei casi uso generalmente Arquillian.


 che gli unit-test li debba scrivere un terzo.



Il terzo sei tu, *prima* di iniziare a scrivere il software, e cioe` prima di aver pensato all'implementazione. Ecco perche` il test-driven design e` l'approccio migliore alla scrittura del software e dei test.

Quella di far scrivere gli unit test a posteriori ad un terzo non e` una soluzione praticabile. Se a posteriori, con un po' di sale in zucca, gli unit test li deve scrivere lo sviluppatore. Uno unit test deve essere conciso e testare UNA sola funzionalita` e bene - e questo aiuta a non fare troppi errori. Come gia` detto, pero`, TDD e` cio` a cui tutti dovrebbero aspirare.




 No, quelli sono semmai test funzionali. Intendo proprio lo unit test, manualmente lo puoi fare con un debugger



Ma cosa c'entra? Questo non e` unit-testing (non ha senso parlare di "unit test manuale"), e` semplice esecuzione passo passo. Lo unit test non serve solo a verificare che il tuo codice funzioni nell'immediato, serve a GARANTIRTI che il tuo codice funzioni e conservi certi behaviour dal momento in cui lo scrivi in poi. Gli unit test vanno eseguiti prima di ogni commit, per garantire che non ci siano bug di regressione. Sul server potrai avere test di integrazione e acceptance che richiederanno piu` tempo.


 Tornando al caso specifico, scrivere codice e poi raddoppiare con gli unit test in un linguaggio come Javascript... bè, veramente tanti auguri.



Ma "tanti auguri" cosa? In JavaScript si puo` fare unit testing esattamente come con qualunque altro linguaggio. Hai mai sentito parlare di Jasmine? Tu pensi che si possa scrivere codice (JavaScript, Java, o il linguaggio Pinco Pallo) senza unit test, oggi? E` assolutamente folle.




 Ecco perche` il test-driven design e` l'approccio migliore alla scrittura del software e dei test.

Hai perfettamente ragione, il problema e' che al crescere della 

complessita' non sempre le cose vanno per il verso giusto.

Ti faccio un esempio, che mi e' successo tempo fa':

Data una certa classe Paperino serializzabile (scritta da qualcun altro) 

con il metodo:

public int doPippo(Pluto pluto);

Questa classe ha passato tutti i test possibili.

A runtime si verifica un errore misterioso apparentemente inspiegabile 

in quanto i test, con gli stessi argomenti, continuavano a funzionare.



L'architettura del runtime, espone i metodi della classe Paperino via 

JMX ed un'altra classe utilizza la classe Paperino  come se fosse 

locale. L'errore era dovuto al fatto che il metodo doPippo modificava 

una proprietà dell'oggetto Pluto, in locale funziona tutto, ma via JMX 

l'oggetto Pluto risultava non modificato.

Convengo che il disegno della classe Paperino poteva essere migliore, 

fatto sta che un terzo, *io*, ha dovuto modificare il disegno della 

classe e relativi test.




 Il terzo sei tu, *prima* di iniziare a scrivere il software



Ci ho riflettuto. L'idea del 'terzo', che puoi mettere tranquillamente 'prima', non è cattiva affatto. 

Io quando sviluppo passo giorni, prima di scrivere una riga di codice, a pensare come deve funzionare anche nei dettagli. Il rischio che corro, in effetti, è che questi pensieri influenzino il test. Avendo ovviamente risorse economiche adeguate, far fare il lavoro a un terzo, che non è nella mia testa, dovrebbe portare a un risultato migliore.



-- 

Ciao!

Luca


 Avendo ovviamente risorse economiche adeguate, far fare il lavoro a un terzo, che non è nella mia testa, dovrebbe portare a un risultato migliore.



Non e` una strada praticabile, e secondo me neanche consigliabile. Gli unit test devono essere disponibili in tempo breve, ed essere lanciati prima di ogni commit (sarebbe consigliabile eseguire uno smoke test generale, prima di committare, ma non e` sempre fattibile). Sono responsabilita` dei singoli sviluppatori. Chiaro che un test scritto male non garantisce granche`, ma questo concerne l'abilita` e l'onesta` intellettuale di ogni singolo programmatore. Se scrivi test per testare il tuo codice, okay; se scrivi test per accontentare il team leader e rispettare i threshold del coverage, e` un altro conto :)


Secondo chi pratica tdd non va fatta una onerosa analisi del codice che si scriverà. O meglio, se sei un genio puoi pure fare così e imbroccarla al primo colpo, altrimenti é meglio se lasci che il disegno cresca un po alla volta test dopo test, revisione dopo revisione.


 difficile garantire che quel codice funzioni. 



Questa è una tua opinione frutto di casini personali: hai dati a supportarla o sono solo chiacchiere da bar?



Ciao

  Francesco




 Questa è una tua opinione[...]



No, non e` una mia opinione, e` un dato di fatto che il TDD porti ad una miglior progettazione del codice. I casini e le chiacchiere da bar saranno la tua specialita`, di certo non la mia. Basta avere un po' di esperienza, d'altronde, per sapere che quel che ho scritto e` vero.



"Kent Beck, who is credited with having developed or 'rediscovered'[1] the technique, stated in 2003 that TDD encourages simple designs and inspires confidence"

https://en.wikipedia.org/wiki/Test-driven_development




"If the code is written first, then it's ipso facto not test-driven, nor does it have the benefit of the TDD design approach of incremental integration."

http://www.drdobbs.com/tdd-is-about-design-not-testing/229218691




"To get the most out of TDD, don't be too dogmatic about its implementation; instead use it as a technique to influence the way you design.  For instance, TDD is really helpful in identifying smells in design."

https://www.thoughtworks.com/insights/blog/using-tdd-influence-design




Ecc... ecc... ecc....


 Chiaro che un test scritto male non garantisce granche`



E chi o che cosa stabilisce, obiettivamente ed inequivocabilmente, se un test è scritto bene o male?  






 E chi o che cosa stabilisce, obiettivamente ed inequivocabilmente, se un test è scritto bene o male?



Lo stesso criterio che adotti per valutare che il tuo codice rispetti o no certi requisiti. Un test e` scritto bene se protegge cio` che puo` rompersi. Questa e` una valutazione che e` piu` o meno facile fare da soli, o con una code review.



Se hai un metodo, in Java, che accetta il path di un file, quali sono i casi di test?


 Ma cosa c'entra? Questo non e` unit-testing (non ha senso parlare di "unit test manuale"), e` semplice esecuzione passo passo. Lo unit test non serve solo a verificare che il tuo codice funzioni nell'immediato, serve a GARANTIRTI che il tuo codice funzioni e conservi certi behaviour dal momento in cui lo scrivi in poi. 



Che stai dicendo? Che se riprendo in modifica una unit non posso (e devo, se opero in quel modo) ripetere il test manualmente prima di committarla? E chi me lo vieta? Roba da matti :-)








 Che stai dicendo? Che se riprendo in modifica una unit non posso (e devo, se opero in quel modo) ripetere il test manualmente prima di committarla? E chi me lo vieta? Roba da matti :-)



Prima di scrivere "Roba da matti", assicurati di aver capito quel che gli altri scrivono, perche` io non ho mai detto che lo unit test ti vieta di eseguire il tuo codice passo passo, quando hai finito di compiere una modifica. Vuoi farlo? Libero di farlo. Io ti ho detto un'altra cosa: che l'esecuzione passo passo *non sostituisce* lo unit test. Non esiste alcun "unit test manuale" come tu erroneamente affermi. Hai modificato la logica della tua unit? Scriverai un nuovo unit test, o modificherai uno esistente, perche` testi la nuova logica. 

O tu forse esegui passo passo TUTTO il codice di un sistema, dopo aver compiuto una modifica, per assicurarti che nessuna funzionalita` e` regredita? Questa, si`, sarebbe roba da matti.








 Lo stesso criterio che adotti per valutare che il tuo codice rispetti o no certi requisiti. Un test e` scritto bene se protegge cio` che puo` rompersi. Questa e` una valutazione che e` piu` o meno facile fare da soli, o con una code review.



In casi un pelino più complessi di un metodo/funzione con 1 parametro nativo, una valutazione personale non è un metodo obiettivo per sapere se il sorgente di un test copre tutti i test richiesti, ed è esso stesso scevro da errori (finchè sono falsi negativi va pure bene, ma se sono falsi positivi...).


 O tu forse esegui passo passo TUTTO il codice di un sistema, dopo aver compiuto una modifica, per assicurarti che nessuna funzionalita` e` regredita? 



Confondi unit test con test di integrazione o di sistema :-)

Comunque in alcuni casi se il "sistema" è molto semplice (un singolo programma) si può anche fare, certo.


 In casi un pelino più complessi di un metodo/funzione con 1 parametro nativo,una valutazione personale non è un metodo obiettivo per sapere se il sorgente di un test copre tutti i test richiesti, ed è esso stesso scevro da errori (finchè sono falsi negativi va pure bene, ma se sono falsi positivi...).



La valutazione personale non e` un metodo obiettivo per definizione. Il punto e` che nessuno e` alla ricerca di "metodi obiettivi". La valutazione soggettiva, se sei una persona intelligente, che sa quel che sta facendo, e` quanto basta. Se a te basta per capire quando hai coperto del tutto i requisiti di un cliente, perche` non dovrebbe bastarti per capire se hai coperto del tutto i requisiti del codice? Quando si scrive uno unit test, si sta testando una porzione minuscola del codice, a volte un singolo metodo: si sta testando *UNA* cosa. E` la regola. Parlare di "sorgente di un test che copre tutti i test richiesti" e` fondamentalmente errato. Un test e` UN test. I casi "un pelino piu` complessi" si dividono in casi meno complessi, fino ad avere qualcosa di facilmente testabile. Si chiama "divide et impera" e si usa, in informatica, dalla notte dei tempi.




 Confondi unit test con test di integrazione o di sistema :-)



Io non confondo proprio niente. Ti ho appunto presentato un caso paradossale. E non sto parlando di test di integrazione/sistema. Sto parlando di unit test. Gli unit test che coprono i test di TUTTO il sistema, perche` scritti per ogni classe che hai implementato nel sistema.


On Monday, 25 January 2016 13:54:29 UTC, Dr.UgoGagliardelli  wrote:



[...]

Ma il fatto che si verifichino errori a runtime, e che certi malfunzionamenti passino tra le maglie dei test, e` perfettamente normale. Quel che bisogna fare e` chiudere i buchi: scrivere un test ogni volta che tali malfunzionamenti si verificano. 



Non conosco nel dettaglio il caso specifico, ma mi sembra di intuire che a runtime c'era un'interazione tra classi che non coperta da nessun test di integrazione. O no?




Scusami IPSAS, mi sorge un dubbio  a questo punto: ma tu hai la benché minima idea di cosa sia un test di regressione?


 La valutazione personale non e` un metodo obiettivo per definizione. Il punto e` che nessuno e` alla ricerca di "metodi obiettivi". La valutazione soggettiva, se sei una persona intelligente, che sa quel che sta facendo, e` quanto basta. Se a te basta per capire quando hai coperto del tutto i requisiti di un cliente, perche` non dovrebbe bastarti per capire se hai coperto del tutto i requisiti del codice? Quando si scrive uno unit test, si sta testando una porzione minuscola del codice, a volte un singolo metodo: si sta testando *UNA* cosa. E` la regola. Parlare di "sorgente di un test che copre tutti i test richiesti" e` fondamentalmente errato. Un test e` UN test. I casi "un pelino piu` complessi" si dividono in casi meno complessi, fino ad avere qualcosa di facilmente testabile. Si chiama "divide et impera" e si usa, in informatica, dalla notte dei tempi.



Partendo dal fatto che i test da fare, inizialmente, sono solo nella capoccia del programmatore (almeno su questo saremo d'accordo! :-), il problema è capire se metterli per iscritto in un codice software sia più affidabile, più obiettivo, più scevro da errori di altri sistemi piu "caserecci".


 Io non confondo proprio niente. Ti ho appunto presentato un caso paradossale. E non sto parlando di test di integrazione/sistema. Sto parlando di unit test. Gli unit test che coprono i test di TUTTO il sistema, perche` scritti per ogni classe che hai implementato nel sistema.



Se hai unit test (per definizione isolano ogni unit dalle altre) che si influenzano tra loro, allora non sono "unit" test, o sono scritti male.


Prima di proporre alternative ai test automatici, devi almeno conoscere un minimo di teoria e pratica. 

Dalle risposte che dai si vede benissimo che non capisci quello che scrive 4ndre4, mentre per me (e penso molti altri) sta scrivendo cose piuttosto note, già lette, studiate e sentite.



Quindi suvvia, un po' di umiltà: studia e solo dopo torna a proporci il debugging come strumento antiregressivo se vuoi (anche se dubito lo farai dopo aver per l'appunto studiato).


 Partendo dal fatto che i test da fare, inizialmente, sono solo nella capoccia del programmatore (almeno su questo saremo d'accordo! :-),



Parzialmente d'accordo. Nello unit testing ci sono delle pratiche, delle 

best practices. Anche se la logica del test e` ovviamente dipendente 

dall'applicazione particolare che stai sviluppando, esistono regole su 

come si scrivono i test.



 >il problema è capire se metterli per iscritto in un codice software 

sia più affidabile

 >più obiettivo, più scevro da errori di altri sistemi piu "caserecci".



Il problema *per chi*? Per te, forse. Cioe` il problema si riduce, PER 

TE (visto che gran parte del resto del mondo degli sviluppatori si e` 

ormai aggiornato) a capire se le tecniche di sviluppo e test del 

software diffusesi negli ultimi 20 anni, fanno al caso tuo. Io credo che 

tu debba seriamente metterti a studiare, ispas.





-- 

4ndr4

"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[...]" - 
http://goo.gl/1nrkkX





Certo, i test erano precedenti all'implementazione del jmx, che chi 

aveva sviluppato non poteva immaginare.


 Se hai unit test (per definizione isolano ogni unit dalle altre) che si influenzano tra loro,

 > allora non sono "unit" test, o sono scritti male.



Se io scrivo "unit test" e tu pensi ad un "integration test", io non 

posso farci proprio niente, caro ispas.

Da quel che scrivi, e` evidente che non sai che cosa e` uno unit test, e 

quasi sicuramente non ne hai mai scritto uno.

La parola "unit" in "unit test" sta ad indicare la piu` piccola parte 

testabile del tuo software, non indica necessariamente una "compilation 

unit". Uno unit test serve a testare una determinata funzionalita` e non 

interagisce con (e quindi non viene influenzato da) altri unit test.

E questo per definizione di "unit". Il test testa la unit, NON le 

interazioni. Comincia a scrivere degli unit test per il tuo software e 

capirai di che sto parlando.



 Prima di proporre alternative ai test automatici, devi almeno conoscere un minimo di teoria e pratica. 



Altro che "automatici", li devi scrivere uno ad uno con santa pazienza (e bei maroni), e direi anche veramente tanta, tanta attenzione, sennò sono tempo perso, vane chiacchere da tromboni elettronici. L'"automatismo" è solo nell'esecuzione.

Un pò di umiltà, suvvia :-)


 Altro che "automatici", li devi scrivere uno ad uno con santa pazienza (e bei maroni)[...]



Ma perche` continui a parlare a vanvera? Perche` non hai l'umilta` di 

informarti su cio` che non sai? L'automaticita` del test non e` nella 

sua scrittura, e` nella sua esecuzione.

E` vero che gli unit test li devi scrivere, ma li scrivi *UNA* volta e 

vengono eseguiti automaticamente quando compili il tuo software, o su un 

integration server, ogni volta che committi. Gli unit test sono pensati 

per essere test automatici che ti proteggono da bug di regressione. 

Spiegaci qual e` l'approccio anti-regressione che tu adotti.



 aveva sviluppato non poteva immaginare.



Ah ecco, quindi il problema e` di chi ha aggiunto l'implementazione del 

JMX. Essendo un sistema che influenza l'interazione tra classi, era sua 

responsabilita` scrivere test di integrazione.



 capirai di che sto parlando.



Visto che tu, a fronte di una modifica di singola unit, vuoi rieseguire: "Gli unit test che coprono i test di TUTTO il sistema, perche` scritti per ogni classe che hai implementato nel sistema", evidentemente non sai cosa scrivi.

Se modifico UNA unit testerò, in isolamento, SOLO quella unit. Manualmente o come altro ti pare.






 per essere test automatici che ti proteggono da bug di regressione. 



Certo, eseguirli in automatico è un vantaggio, ma l'utilità vera dipende poi dalla validità di cosa ci hai scritto dentro.

Che non è una critica ma un punto di attenzione. 

Se per te non lo è, se li scrivi di getto senza mai fare errori logici o banali refusi, ti faccio i complimenti. 


  Se a te basta per capire quando hai coperto del tutto i requisiti di un cliente, perche` non dovrebbe bastarti per capire se hai coperto del tutto i requisiti del codice? 



Perché il cliente per definizione è un essere diabolico. Lui ti dice 10, tu pensi: se realizzo 100, copro anche quel che non mi ha detto... Ebbene, lui domani mattina pensa a 101!!!



:-D



-- 

Ciao!

Luca


 Oggi, NESSUNO che programmi seriamente, usa i test manuali in alternativa agli unit test. 



E vabbé, io non programmo seriamente: sono colpevole, di tanto in tanto non uso lo unit testing! E ora spara!



:-DDDDD



-- 

Ciao!

Luca




No mi spiace, la risposta è stata del cazzo.

La domanda l'avevo fatta per capire la disponiblità dietro a quello che 

parrebbe un approccio fondamentale nello sviluppo del sw da adottare in 

una realtà dove è sconosciuto.

E per il ben pagato, mi spiace (a me intendo...), ma la mia paga è media 

tendente al basso (di fatto ferma ai livelli del 2008), quindi hai 

risbagliato di nuovo...




 Visto che tu, a fronte di una modifica di singola unit,vuoi rieseguire: "Gli unit test che coprono i test di TUTTO il sistema,

 > perche` scritti per ogni classe che hai implementato nel sistema", 

evidentemente non sai cosa scrivi.

 > Se modifico UNA unit testerò, in isolamento, SOLO quella unit. 

Manualmente o come altro ti pare.



Io so benissimo cosa scrivo, caro ispas. Sei tu che non hai la minima 

idea di cosa sto dicendo, e perche` non hai la minima esperienza 

professionale con le tecniche di testing che sono ormai in voga da 20 

anni. Se tu modifichi il codice di una classe, mettiamo un metodo, e` 

chiaro che eseguirai il test di quella classe o del metodo. Il punto e` 

che tu stai proponendo un test manuale come alternativa al test 

automatico. Significa che se modifichi 100 classi (perche` in un 

contesto professionale, e` molto improbabile che tu modifichi una sola 

riga di un solo metodo, di una sola classe, ogni volta), che fai, ti 

metti a ritestare tutte e 100 le classi manualmente? E come fai a 

garantire, che stai testando TUTTE le possibili interazioni con i 

collaboratori? Sentiamo.





Perché nel resto dello sviluppo no?

Perché si deve arrivare a scrivere unit test per capire se il proprio 

codice è fatto bene? Non lo si può imparare a fare a monte, senza unit test?








Non è già così quando si fa refactoring continuo durante lo sviluppo?

Che aggiunge di speciale lo unit test?




ma l'utilità vera dipende poi dalla validità di cosa ci hai scritto dentro.



Hai scoperto l'acqua calda. Il punto che si sta cercando di farti capire 

e` che, considerato che uno unit test copre una parte minuscola di 

codice, compiere degli errori e` molto improbabile. Il motivo per cui 

gli unit test DEVONO essere concisi e testare UNA sola funzionalita` e` 

anche quello di evitare troppa logica e conseguenti errori.



 di tanto in tanto non uso lo unit testing!



No, non e` serio. Se lo fai professionalmente, non e` serio. Significa 

fare acrobazie senza rete di sicurezza.



 test?



Aridalle. Le attivita` di testing automatico non servono a "capire se il 

proprio codice e` fatto bene". Servono a coprirti dai bug di 

regressione. Imparare a scrivere bene il codice e` necessario ma, come 

ti e` stato gia` spiegato, non e` sufficiente. In che modo garantisci, 

tu che sai scrivere bene il tuo codice, che non hai fatto regredire il 

tuo sistema, ogni volta che compi una modifica?



On 25/01/2016 19:42, Luca Menegotto wrote:

[...]

 > Lui ti dice 10, tu pensi: se realizzo 100, copro anche quel che non 

mi ha detto...



Sbagliato. E` per questo che a mio parere Agile/Scrum e` un buon metodo 

di lavoro. Non cadi nello YAGNI.



 Che aggiunge di speciale lo unit test?



Il refactoring continuo, durante lo sviluppo, serve a migliorare 

costantemente la qualita` del codice, non e` legato al design del 

codice. Si sta parlando di TDD, non strettamente di unit test. E` 

difficile spiegarti perche` TDD e` cosi` importante per la 

progettazione, se non hai le basi ne` sullo unit testing, ne` sul TDD. 

Dovresti prima studiarti qualcosa.



 fare acrobazie senza rete di sicurezza.



Ma anche no. Basta sapere quel che stai facendo. Se penso che ci possano essere criticità, non si transige; ma se a) non ci possono essere criticità e b) si tratta di piccole funzionalità che devono essere pronte per ieri, si va senza UT.



Ho appena finito (venerdi, per la verità) di scrivere 300 righe di Python. Una giornata, test compresi. Va come un orologio.

Vogliamo fidarci un attimo dell'imbecille che batte i tasti?



E' ovvio che se si parla di roba un attimo più complessa, le cose cambiano - ma pure l'approccio.



-- 

Ciao!

Luca


 di lavoro. Non cadi nello YAGNI.



Il problema è che uno dei principi base dell metodo Agile è che deve essere condiviso (*). Talora non mi pagano abbastanza per spiegare il metodo e condividerlo (aggiungo, purtroppo).



(*) E' per me l'ideale da raggiungere, e mi leverebbe molti mal di testa. Ma spesso il cliente/committente ha un'idea differente. Come sai, pecunia non olet, in questo periodo, per cui mi adatto.



-- 

Ciao!

Luca


 Nel 2016 chi sviluppo non può non farlo via unit testing?



Non si sviluppa *via* unit testing. Lo vedi? Non sai manco che cos'e`.



 tendente al basso (di fatto ferma ai livelli del 2008)



Visto che quel che scrivi, la cosa non mi sorprende affatto.





Mi fai un esempio di come una modifica possa far smettere di funzionare 

qualcosa che funzionava?




 Ma anche no. Basta sapere quel che stai facendo.



Siamo alle solite. Purtroppo sono concetti che non vi entrano in testa, 

e c'e` poco da fare. Ti sbagli: anche quando si tratta di piccole 

funzionalita` che devono essere pronte per ieri, si usa lo unit testing.

In ambito professionale, lo unit testing si usa comunque e sempre.

Spiega qual e` l'approccio che usi per garantire che quelle "piccole 

funzionalita`" non regrediscano.





Beh se andate avanti a mischiare unit test e tdd che volete? E per 

fortuna che voi sapete di che si parla.






Vuol dire che puoi star tranquillo che non perderai il tuo lavoro per 

colpa mia, sentiti fortunato, dai.




 qualcosa che funzionava?



https://en.wikipedia.org/wiki/Software_regression




 funzionalita`" non regrediscano.



Ah, semplice:

1) le tocco solo io e solo se serve (se);

2) sono soluzioni temporanee, tra una settimana (non sto buttando una cifra a caso, è proprio così) il relativo codice verrà buttato via e non più riutilizzato.



Se sai che la durata è finita e molto, molto breve, la probabilità di regressione precipita.



-- 

Ciao!

Luca


 Il problema è che uno dei principi base dell metodo Agile è che deve essere condiviso (*)



Una porzione della metodologia Agile la puoi seguire anche da solo. Non 

e` strettamente necessario lavorare in team. Lo unit testing e` qualcosa 

che prescinde dal lavoro in team.



A proposito, qualcuni sa se esistono i decorators 'a la Python' in C#?



:-)



-- 

Ciao!

Luca


E' la teoria base: se fai refactory senza test hai introdotto bug di regressione.


 collaboratori? Sentiamo.



Rilancio la palla a te, maestro (con la m minuscola :-)): poniamo che hai un metodo con 2 parametri da 10 valori ciascuno, totale 100 combinazioni possibili. Direi un metoduccio, robetta. Quindi nel test ci scrivi tutte e 100 le possibili chiamate con le possibili coppie? Oppure quante ce ne scrivi? 

E se nel metodo hai non 100, ma 1000 combinazioni (situazione già più interessante, ma direi banale) ti metti a scrivere 1000 chiamate? Chiedo, eh.




 2) sono soluzioni temporanee, tra una settimana (non sto buttando una cifra a caso, è proprio così)

 > il relativo codice verrà buttato via e non più riutilizzato.



Questo non e` il modo di lavorare del 99.999% delle aziende di sviluppo 

software del mondo, per cui non puoi fare di questo punto un esempio 

valido di come si possa lavorare.



 Una porzione della metodologia Agile la puoi seguire anche da solo. 



Però, a veder bene, un'altro principio base della metodologia Agile è che è olistica. Il che, capiamoci, per me sarebbe l'ideale.



-- 

Ciao!

Luca


 colpa mia, sentiti fortunato, dai.



E` un problema che non mi sono mai posto.



 fortuna che voi sapete di che si parla.



Infatti io, almeno, so benissimo di cosa si parla. Il problema e` che 

qui dentro ci sono quelli che mio nonno chiamava "ciucci e presuntuosi".



 responsabilita` scrivere test di integrazione.



E magari con una sessioncina di debugger, ma che dico, con 4 system.print messe al posto giusto, sistemavano tutto in 1/10 del tempo senza sbattersi ore o giorni con gli unit test bacati... :-)



(*) mi scuserà il dr. ugo, persona che stimo, però non potevo resistere :-)


 valido di come si possa lavorare.



Non mettermi in bocca cose che non ho detto.

Ho detto che ci sono occasioni (questa è una) in cui non viene adottato il TDD. Sottointendendo (ma occorreva davvero dirlo) che si tratta di eccezioni.



-- 

Ciao!

Luca


poniamo che hai un metodo con 2 parametri da 10 valori ciascuno,

 >totale 100 combinazioni possibili.



La tua domanda non ha alcun senso. Si deve sapere qual e` lo scopo del 

metodo, per poter scrivere i test. Nel TDD, il metodo e` invece frutto 

del test, il che significa che devi sapere a monte cosa testare.



 Ho detto che ci sono occasioni (questa è una) in cui non viene adottato il TDD.



Io non ho interesse a metterti in bocca un bel niente. Io ho affermato 

che oggi non si lavora, in nessun campo dove ci sia un minimo di 

professionalita`, e dove si sviluppi software con un minimo di 

complessita`, senza dotarsi di unit testing, integration testing, system 

testing, acceptance testing, end-to-end testing, continuous integration, 

etc.. Se il tuo caso non ricade in questi, mi spiace, ma sei TU la mosca 

bianca. Se tu vuoi far passare il messaggio, con il tuo "ma anche no", 

che esista una fetta consistente di software che si scrive senza tutti 

quegli strumenti ormai indispensabili, e per farlo usi il tuo 

particolare esempio di software temporaneo usa e getta dopo una 

settimana, allora stai volutamente distorcendo la realta`. L'occasione 

che citi e` probabilmente piu` unica che rara, per cui non fa proprio 

testo. Io sto parlando di unit testing, poi, non necessariamente di TDD.



 anche quello di evitare troppa logica e conseguenti errori.



Non è che hai risolto tutto così facilmente. Invece di scrivere un test relativamente complesso, ne dovrai comunque scrivere 10, 100, 1000 sia pure più semplici. Così facendo hai sicuramente ridotto la probabilità di errore? Diciamo che è una speranza, più che una certezza. Ci vuole ottimismo, ma si :-)




Vabbeh, ma era per prendere un caso pratico reale.

Per vedere che cappella era stata fatta a monte nel codice.

Un esempio dal real world insomma.




 Però, a veder bene, un'altro principio base della metodologia Agile è che è olistica.



Olistico, per Agile, ma sarebbe meglio dire Scrum, significa che nessuno 

va per la propria strada, ma tutti puntano, con disciplina, 

all'obiettivo. Nella mia azienda, c'e` una persona che al momento sta 

lavorando, da sola, su un prodotto, eppure segue la stessa metodologia 

di lavoro di tutti gli altri. Certo, non ha daily standups o 

retrospectives, ma presenta le nuove funzionalita` nelle sprint review 

ed usa il framework di testing che usano tutti.





Infatti.




On 25/01/2016 20:42, ispas wrote:



[...]

Siamo sempre li`. Tiri fuori sorrisini stupidi, fai battutine, ma 

continui ad ignorare che cos'e` lo unit testing. Si vede benissimo che 

non sai cosa sia - e come puoi criticare una metodologia di lavoro che 

non hai mai usato? Continuare a ribattere sulla validita` di una 

metodologia di testing che e` ormai collaudata da un ventennio, e 

pretendere di metterla in discussione con il tuo sarcasmo spicciolo, non 

ti aiuta per niente. Poi, per carita`, magari tu sei un genio che 

rivoluzionerebbe il modo di testare il software oggi, per cui ti invito, 

se hai delle obiezioni tecniche da fare, a pubblicare un articolo su 

come si dovrebbe testare il software, oggi. Lo sottoponiamo a peer 

review da parte di Kent Beck o Martin Fowler e vediamo cosa ne viene 

fuori. Che ne pensi?



 Guarda che sei te che capisci B quando dico A!



Ci vuole un bel coraggio. Tu non sai minimamente cosa sia lo unit 

testing, non lo hai mai usato in vita tua; ti viene detto che usare un 

linguaggio come TypeScript in alternativa a JavaScript "liscio" non 

evita necessariamente l'insorgere di bug di regressione (anche qui: non 

hai la minima idea di cosa siano, visto che chiedi come fa un software a 

regredire). Ti viene detto che lo unit testing e` comunque necessario 

nella scrittura del software, e tu continui a ribattere "si`, ma io uso 

TypeScript". Ora, caro AleTV, ti garantisco che, tra me e te, non sono 

io quello che prende fischi per fiaschi.



 La tua domanda non ha alcun senso. 



Ha tanto senso quanto la tua. 




 fuori. Che ne pensi?



Ma prego, prima lei. Io non ho la pretesa di rivoluzionare un bel niente.




 Ha tanto senso quanto la tua.



No, la TUA domanda non ha senso, la mia si`, e ti e` stato anche 

spiegato il perche`.



 E che, ti dovrei pure prendere sul serio? :-)



Figurati, e` evidente che fare la figura del coglione e` la cosa che ti 

riesce meglio. Ci metto una faccina: :-)



 E magari con una sessioncina di debugger, ma che dico, con 4 system.print messe al posto giusto,

 > sistemavano tutto in 1/10 del tempo senza sbattersi ore o giorni con 

gli unit test bacati... :-)



Di bacato, qui, c'e` solo il tuo cervello, caro ignorantone incompetente.



 una metodologia di testing che non conosci minimamente.



Diciamo però che come evangelist del TDD non vali un ciufolo, non ne hai convinto manco uno, eh... :-)


 Diciamo però che come evangelist del TDD non vali un ciufolo,

 > non ne hai convinto manco uno, eh... :-)



Di convincere gente come te, ignorante, stupida e incompetente, non e` 

mia intenzione. Anche perche` la gente come ti non si puo` "convincere". 

Per essere persuasi che qualcosa e` valido bisogna essere innanzitutto 

intelligenti (e tu non lo sei), avere una mente aperta (e tu non ce 

l'hai), essere un minimo competenti (e tu non lo sei), e voler imparare 

(e tu non vuoi). Ma non e` neanche mia intenzione convincere nessuno. Se 

vuoi lavorare bene, e` una tua scelta. Se non vuoi farlo, a me la vita 

non cambia. Il mio lavoro ce l'ho, le mie soddisfazioni pure. Ti faccio 

un in bocca al lupo, perche` la gente come te ne ha bisogno. Faccina: 

:-) E ci metto anche un bacetto: :-*





Nessun coraggio, tu sei andato in loop.

Stai aggiungendi pezzi in corsa e ora sei arrivato ai test di regressione.

Quando invece fai finta di non capire quanto sia ovvio che usare 

typescript invece del js liscio sia naturalmente un mezzo per scrivere 

meno codice bacato causa la natura di js.

Vuoi che andiamo avanti? Io a dire A e tu ripetere B?

Prego.




 Stai aggiungendi pezzi in corsa e ora sei arrivato ai test di regressione.



Non sto aggiungedo proprio niente. Lo unit testing ti e` stato 

menzionato dall'inizio. E lo scopo dello unit testing (come di altri 

tipi di testing) e` di proteggerti da bug di regressione - bug di 

regressione che tu non sai neanche cosa siano.



4 (QUATTRO) giorni fa ti scrivevo:

"[...] I constraint non ti riparano da bug di regressione. Mi par facile 

come concetto."



7 (SETTE) giorni fa, rootkit ti scriveva:

"perché non risolvi nessuna questione a monte. jasmine è un testing

framework che si usa anche con typescript."



E tu continui. Continui a insistere con la stronzata di "TypeScript al 

posto di JS liscio" contrapponendola all'uso degli unit test. Non si 

puo` fare nulla: e` pura stupidaggine.



 regredire).

Ti ho chiesto un esempio preso dal mondo reale.

Visto che fai unit test e tdd di continuo, magari ti veniva facile tirar 

fuori un caso di una modifica che aveva rotto funzionalità funzionanti...

Perché della richiesta? Per capire il tipo di cappella introdotta e come 

è entrata visto che a monte pure nel codice quotidiano ci sono delle 

linee guida da rispettare, e come mai queste non siano state sufficienti.






Ok, non vuoi ammettere che typescript sia meglio di js liscio e che già 

solo questo è un mezzo per scrivere molti meno bachi. E ti nascondi 

dietro agli unit test in loop perché io non ne ho mai fatti, cosa 

scritta chiaramente fra l'altro.

Ma vuoi che ti faccio un bonifico così ti senti gratificato 

concretamente e ti senti libero di fare un break dal tuo loop?




 :-) E ci metto anche un bacetto: :-*



Mi fa piacere. Tanti auguri anche a te. 






On 25/01/2016 21:24, ispas wrote:



[...]

 > Appero, eppure hai scritto almeno una ventina di messaggi 

sull'argomento. Pensa se volevi veramente convincere qualcuno ... :-)



Stai tranquillo che non li ho scritti nel tentativo di convincerti di 

niente. Li ho scritti per ribattere alle cazzate che tu affermi, da 

ignorante e incompetente quale sei.



 Ok, non vuoi ammettere che typescript sia meglio di js liscio



Guarda che "in loop" ci sei entrato tu, e perche` ti ostini a non capire 

quel che gli altri scrivono. Io non mi "nascondo" dietro un bel niente, 

perche` non ho proprio bisogno di farlo. Io lo so benissimo che 

TypeScript risolve alcuni problemi rispetto a JS liscio. Non e` questo 

che si sta mettendo in discussione. Quel che da almeno una settimana si 

sta cercando di far entrare nel tuo cervello e` che usare TypeScript non 

e` un'alternativa a JS + unit test!



Io ti ho scritto: "JavaScript ha dei grossissimi difetti, ma si rimedia 

adottando delle convenzioni specifiche, concentrandosi sulle "good 

parts", e sopratutto facendo unit-testing, una pratica purtroppo da 

molti ancora ignorata. Esistono framework come Jasmine che consentono di 

coprire gran parte dei potenziali casi di errore. Nella mia azienda, 

abbiamo un intero team che sviluppa in JavaScript, e grossi problemi non 

ne incontriamo."



Tu hai risposto: "Perché usare framework orientati a js quando si può 

usare un'alternativa che è di fatto un linguaggio migliore"



Te lo ripeto: TypeScript non e` un'alternativa agli unit test. 

JavaScript ha dei pitfalls evidenti, che sono da aggirare concentrandosi 

su quelle che Crockford chiama "good parts" e ignorando tutto il resto. 

Bisogna usare unit test in JavaScript come in qualunque altro 

linguaggio. Non e` indispensabile muoversi su TypeScript. Vuoi farlo? 

Bene. Ma dovrai dotarti di unit test ANCHE in TypeScript.



 che citi e` probabilmente piu` unica che rara,



1) E' meglio se ti rileggi: prima dici che non mi metti in bocca nulla, poi è esattamente quel che fai.

2) Occasione più unica che rara un paio di ciufole, purtroppo. Magari tu non ne hai esperienza, ma non è detto che non esista.



Ho detto.



-- 

Ciao!

Luca


 ignorante e incompetente quale sei.



Io sono tranquillissimo, ti avevo anche fatto pure gli auguri, più educazione neh....


 linee guida da rispettare, e come mai queste non siano state sufficienti.



Le linee guida - ti si sta cercando di far capire - non sono 

sufficienti. I bug di regressione sono spesso dovuti a dimenticanze, 

disattenzioni, distrazioni. Ti posso fare un esempio semplice:



public class Person {

     private final String firstName;

     private final String lastName;



     public Person(String firstName, String lastName) {

         this.firstName = firstName;

         this.lastName = lastName;

     }



     public String getFullName() {

         return String.format("%s %s", lastName, firstName);

     }

}



Un domani qualcuno (magari anche tu stesso), nel modificare il codice, 

riscrivi il codice della classe, e inverti i due parametri:



public String getFullName() {

    return String.format("%s %s", firstName, lastName);

}



Che fai, aspetti che il tuo cliente sollevi un bug in produzione 

dicendoti che il tuo sistema gli sta stampando tutti in nominativi 

errati, o ti doti di uno unit test:



public class PersonTest {

     @Test

     public void testGetFullName() throws Exception {

         Person person = new Person("Mario", "Rossi");

         assertThat(person.getFullName(), is("Rossi Mario"));

     }

}



Se un domani commetti l'errore di passare i parametri al contrario, 

avrai un bel fail:



java.lang.AssertionError:

Expected: is "Rossi Mario"

      but: was "Mario Rossi"



e sara` un bug che risolverai in sviluppo, risparmiandoti tempo, soldi, 

e dolore.



 Io sono tranquillissimo[...]



Vai a studiare, e` meglio per te, ignorante.





Mi spieghi come fai con gli unit test ad ottenere lo stesso 

comportamento che si ha con i constraint di typescript?

Ovviamente non direttamente in compilazione perché è impossibile.

E poi perché uno dovrebbe scrivere quintalate di test per scoprire via 

unit test quello che type script ti rende evidente subito in compilazione?




 Vai a studiare, e` meglio per te, ignorante.



Va bene, cioè male, ti auguro i peggiori tormenti (cioè unit test falsi positivi a pioggia) ... :-))




 1) E' meglio se ti rileggi: prima dici che non mi metti in bocca nulla, poi è esattamente quel che fai.



Ti ripeto che non ti sto mettendo in bocca nulla. Io sto parlando dello 

sviluppo software in generale. Basta affacciarsi su un sito di annunci 

di lavoro, guardare le richieste di lavoro per figure senior, per 

accorgersi di quali sono i requisiti e i tool di lavoro che sono 

richiesti. Basta sfogliarsi la pagina "Job Vacancies" delle aziende piu` 

tecnologicamente attraenti del settore, per capire come si lavora.

Fatti un giro, non devi necessariamente fidarti di quel che dico io. 

Come sviluppi software tu, nel tuo piccolo, non fa testo, perche` la 

situazione che presenti, quella di software temporaneo che viene buttato 

via dopo una settimana, e` come lavora forse lo 0.00001% (e forse anche 

meno) delle aziende software mondiali. Si`, e` un'occasione piu` unica 

che rara. E` chiaro che se non hai bisogno di fare manutenzione al 

codice, nel tempo, non adotterai le tecniche che servono a supportare 

quella manutenzione. La stragrande maggioranza delle aziende software, 

pero`, scrive software e lo mantiene.



 Va bene[...]



Continui a perdere tempo. Tempo rubato allo studio.



 unit test quello che type script ti rende evidente subito in compilazione?



Perche`, come gia` ti e` stato spiegato duemila volta, gli unit test 

devono essere eseguiti automaticamente e ti proteggono dai BUG DI 

REGRESSIONE.



 Scusami IPSAS, mi sorge un dubbio  a questo punto: ma tu hai la benché minima idea di cosa sia un test di regressione?



Interessante il fatto che non ti abbia risposto. Lui butta merda a 

palate sulle tecniche di testing, pero` si guarda bene dal far presente 

come garantisce, lui, che il suo software non regredisca. Ah, no, 

dimenticavo, lui fa debug passo passo. LOL :)



-- 

4ndre4



 (*) ed, aggiungo, ovviamente mock, stub, e tutti gli indispensabili collaterali fatti apposta ed unicamente per i test.



a parte che scrivere un mock è più noioso che complicato, ma almeno l'hai

capito a cosa servono? ho ripescato una discussione di sei anni fa e

facevi le solite identiche domande fesse:

https://goo.gl/OJRVDw


voglio dire, in sei anni ci si laurea con tanto di specializzazione ma 

te sei sempre lì a girare in tondo. per quanto mi riguarda direi anche basta.


 Vai su Amazon, puoi iniziare da un paio come "Clean code" e "Growing object oriented software, guided by tests".



Ottimo consiglio. e aggiungo:



xUnit Test Patterns: Refactoring Test Code - Gerars Meszaros

Test Driven: TDD and Acceptance TDD for Java Developers - Lasse Koskela

Effective Unit Testing: A guide for Java developers - Lasse Koskela

Test-Driven Development: By Example - Kent Beck

The Art of Unit Testing: with examples in C# - Roy Osherove

Agile Software Development, Principles, Patterns, and Practices - Robert 

C. Martin

Continuous Delivery: Reliable Software Releases Through Build, Test, and 

Deployment Automation - Humble, Farley



 A proposito, qualcuni sa se esistono i decorators 'a la Python' in C#?



https://msdn.microsoft.com/en-us/library/z0w1kczw(v=vs.80).aspx




In C# si chiamano attributes. In Java sono annotations.



 Ti ripeto che non ti sto mettendo in bocca nulla. 





Andrea, davvero, ogni tanto ti piace fare l'integralista. Riporto quel che ho scritto, perché da li si parte:



"E vabbé, io non programmo seriamente: sono colpevole, di tanto in tanto non uso lo unit testing! E ora spara!



:-DDDDD "



allora:

1) 'di tanto in tanto' ha un significato preciso, in italiano corrente; ti metto un sinonimo: "occasionalmente"; vuol dire: normalmente non è come mi comporto, ma capita in casi molto particolari (e negli altri due messaggi che ho postato l'ho ribadito);

2) ci ho messo pure un bello smiley, a indicar battuta.

Il resto lo hai aggiunto tu.



-- 

Ciao!

Luca


 In C# si chiamano attributes. In Java sono annotations.



Pure in Python si chiamano attributes; ma non sono decorators. Non so quanto conosci Python, per cui permettimi se mi dilungo un attimo.

Python ha due principi base che in questo caso vengono utili:

1) tutto è un oggetto, funzioni e classi comprese;

2) tutti gli oggetti sono dinamici.

Questo fa si che si possono fare anche cose pericolose assai; però comporta anche che tutta l'infrastruttura di introspection presente di C# in Python è semplicemente inutile: aggiungere un attribute a una classe o a una funzione è questione di una riga di codice.

In Python i decorators sono uno strumento potente che consente, in modo molto elegante, di incapsulare una funzione richiamabile all'interno di un'altra, al fine di poter eseguire codice prima e dopo la funzione stessa, in modo assolutamente trasparente al chiamante.

Ora che lo rileggo, mi rendo conto che, proprio per struttura, in C# questa cosa è complessa assai (esistono dei pattern, ma sono insoddisfacenti).



-- 

Ciao!

Luca


 No, non e` una mia opinione, e` un dato di fatto che il TDD porti ad una 



Quelli sotto non sono studi sono o opinioni o fonti secondarie basate su opinioni.



Ti ho chiesto STUDI esattamente come spesso fai tu: ne hai o no?



Ciao

  Francesco


 Ti ho chiesto STUDI esattamente come spesso fai tu: ne hai o no?



Hai fatto una domanda stupida. Lo unit testing non e` materia di studio scientifico. Vorresti che ti citassi un articolo su Nature su cui i vari scienziati fanno peer review delle tecniche di testing? LOL :) La validita` di tutte le tecniche e metodologie che si adoperano in programmazione sono frutto di esperienza, a volte un'esperienza molto lunga. Quelle che ho riportato sono (una parte delle tante) conclusioni di fonti autorevoli, in campo informatico. Mi spiace, ma e` evidente che non hai esperienza a sufficienza per capire quel che sto dicendo. Se non sai che DrDobb's, ThoughtWorks e Kent Beck sono fonti autorevoli, il problema e` tuo. 


 Andrea, davvero, ogni tanto ti piace fare l'integralista. Riporto quel che ho scritto, perché da li si parte:



Integralista un cazzo. Tu stai cercando di far passare messaggi errati, e mi stai erroneamente accusando di metterti in bocca cose che non dici. Il fatto che "di tanto in tanto" tu scriva software senza usare unit testing non e` poi cosi` rilevante per nessuno. Te lo ripeto: che cosa TU faccia, nel TUO piccolo, non e` poi cosi` interessante. Ti ho scritto: "Come sviluppi software tu, nel tuo piccolo, non fa testo, perche` la situazione che presenti, quella di software temporaneo che viene buttato via dopo una settimana, e` come lavora forse lo 0.00001% (e forse anche meno) delle aziende software mondiali. Si`, e` un'occasione piu` unica che rara. E` chiaro che se non hai bisogno di fare manutenzione al codice, nel tempo, non adotterai le tecniche che servono a supportare quella manutenzione. La stragrande maggioranza delle aziende software, pero`, scrive software e lo mantiene."



Se tu affermi "io non programmo seriamente: sono colpevole, di tanto in tanto non uso lo unit testing!", si`, non programmi seriamente. Se quelle funzionalita` sono destinate ad un cliente, non ti stai dotando degli strumenti che garantiscono che quelle funzionalita` non regrediscano. Vuoi fare il muratore senza casco, rete di protezione, o scarpe antinfortunistiche? Fallo pure, ma non reclamare che questo e` un modo valido di lavorare, tanto quanto quello degli altri. 


 In Python i decorators [...]



Lo so che cosa sono i decorators in Python. Si tratta del classico Aspect Oriented Programming, che si puo` fare sia in Java che in C#. Spring, ad esempio, implementa AOP.




 Non hai capito: quelli che si chiamano "decorators" in Python, sono gli "attributes" in C# e le "annotations" in Java. Gli attributes di Python non c'entrano.



In realta`, gli attributes/annotations hanno usi piu` ampi che il semplice AOP. Sarebbe giusto dire che l'equivalente dei decorators Python sono attributes/annotations usati in ambito AOP.


 scientifico. 



Ah no? Peccato che siano decenni che l'ingegneria del software è sottoposta a studi scientifici, nel suo piccolo anche il TDD.



Quindi, al di la di quello che dice l'oste, hai mai approfondito la cosa o parli per la tua rispettabilissima esperienza personale?



Ciao

  Francesco


 Integralista un cazzo. 



Ecco, appunto. QED.

Andrea, ascolta lo zio Luca, fattela una risata, ogni tanto. Ti fa solo bene.



-- 

Ciao!

Luca




 Non hai capito: quelli che si chiamano "decorators" in Python, sono gli "attributes" in C# e le "annotations" in Java. 



No. Non conosco Java, ma conosco piuttosto bene C#. Ho usato intensivamente questi e quelli. E gli Attributes di C# poco hanno a che fare coi decorators di Python.



-- 

Ciao!

Luca


 Quindi, al di la di quello che dice l'oste, hai mai approfondito la cosa o parli per la tua rispettabilissima esperienza personale?



scusa se mi permetto, la discussione mi pare prenda una piega piccosa.

articoli accademici e tesi sui benefici (e anche i non benefici) 

della tdd sullo sviluppo ce ne sono a badilate basta cercare con 

le keyword in inglese. 

se vuoi dei riferimenti più precisi posso dirti che nell'autunno 2015 

avevo seguito un corso su coursera dove c'erano interessanti lecture 

sull'argomento.




Quindi, al di la di quello che dice l'oste, hai mai approfondito la cosa o parli per la tua rispettabilissima esperienza personale?



Chi sarebbe l'oste? L'oste sarebbe un mondo dell'informatica in cui certe tecniche sono state applicate, e i vantaggi derivanti sono stati ottenuti, nell'ultimo ventennio? Non c'e` miglior "approfondimento" di qualcosa, che usarlo tutti i giorni, per anni. E le conclusioni che si traggono, sono conclusioni valide, se la tua produttivita` aumenta oggettivamente, la struttura e qualita` del tuo codice migliora, la manutenzione del tuo codice e` piu` facile, non ci sono studi scientifici che tengano. 



D'altronde, la prossima volta che qualcuno afferma che alle variabili bisogna assegnare nomi non ambigui, o che un metodo non deve essere troppo lungo e arzigogolato, che un software deve essere modularizzato, ecc... chiedigli qual e` lo studio scientifico dove tutto questo viene dimostrato. 



Quel che io affermo e` sicuramente frutto di "casini", ma non di "casini personali". Casini, semmai, fatti da altri, e che io sono stato spesso chiamato a correggere. Casini fatti per gli stessi motivi per cui cosi` tanti imbecilli, in questo ng, continuano a polemizzare, senza fiondarsi sui libri e studiare, invece.






On Tuesday, 26 January 2016 10:45:14 UTC, Luca Menegotto  wrote:



[...]

Fino a che taglierai i messaggi degli altri, concentrandosi sempre su cosa ti fa comodo, e` chiaro che vedrai sempre e solo integralisti.





Non ho ne abitudine ne voglia di riportare per l'ennesima volta cose già dette sulle quali (non so perché la cosa non ti piaccia) siamo sostanzialmente d'accordo.

Se invece la vogliamo mettere sul chi l'ha più lungo, guarda, tranquillo, il più lungo è il tuo (qui conta anche l'età, oltre alla voglia e al tempo(*)... )



(*) questa è una battuta.



-- 

Ciao!

Luca


 No. Non conosco Java, ma conosco piuttosto bene C#. Ho usato intensivamente questi e quelli. E gli Attributes di C# poco hanno a che fare coi decorators di Python.



Gli attributes di C#, usati in contesto AOP (cosa che, di nuovo, hai accuratamente tagliato, dal mio post) sono il modo in cui implementi, in C#, il meccanismo analogo ai decorators Python. Mi spiace, ma se sei poco informato su questo, non e` colpa mia. Inizia da Google, e muoviti da li`.










 Non ho ne abitudine ne voglia di riportare per l'ennesima volta cose già dette



E` meglio che non lo fai, perche` riceveresti le stesse risposte, dal momento che continuare a riportare fesserie, le lascia sempre e solo fesserie. E il fatto che tu riduca una discussione tecnica sul "chi ce l'ha piu` lungo", la dice lunga su quanto tu sia sicuro dei tuoi argomenti.







E pensa ad averlo come collega o dipendente, uno cosi'.


 una discussione tecnica sul "chi ce l'ha piu` lungo", la dice lunga su quanto tu sia sicuro dei tuoi argomenti.



Su questo hai ragione. Io non sono mai sicuro di nulla, c'è sempre da imparare. E lo dico dopo quasi 30 anni di onorata carriera.

Flglio mio, in questo caso la discussione tecnica proprio non c'è. Hai preso una battuta e ci hai fatto uno sbrodolamento. Vai a rileggere, se non mi credi.



-- 

Ciao!

Luca






 Mi spiace, ma se sei poco informato su questo, non e` colpa mia. Inizia da Google, e muoviti da li`.



Veramente ho dalla mia non solo Google ma un bel po' di libri e documentazione. Come dicevo in altro post, io però ho sempre dubbi. Partiamo dalle basi, giusto per capire se stiamo dicendo la stessa cosa.



Mi definisci per piacere un decorator in Python e un Attribure in C#?



-- 

Ciao!

Luca




 Io sto affermando che non ho riferimenti scientifici da darti, ma che mi >basta la mia esperienza personale - che e` rilevante nel valutare QUALUNQUE >metodologia di sviluppo software - per confermare che quel che certe fonti >autorevoli dell'informatica affermano, quando parlano dei benefici del TDD, e` >vero. 



Ottimo quindi ritieni che la tua opinione personale abbia peso e quella degli altri utenti di questo newsgroup, come spesso hai affermato, non valgono.



Il resto era solo un modo per capire il tuo pensiero.



Ciao

  Francesco



P.S. Plonk


P.S. Plonk 



LOL :) Il solito mezzo di chi e` incapace di difendere i propri argomenti.


in questo caso la discussione tecnica proprio non c'è. 



Infatti non c'e`. Non c'e` proprio. C'e` solo un mare di imbecillita` sfoderate da te. E io scemo che continuo a risponderti.


 Veramente ho dalla mia non solo Google ma un bel po' di libri e documentazione.



Ne dubito, dal momento che sia Google, che un bel po' di libri su Aspect Oriented Programming dicono l'esatto contrario di quel che hai scritto.


 Infatti non c'e`. Non c'e` proprio. C'e` solo un mare di imbecillita` sfoderate da te. E io scemo che continuo a risponderti.



L'hai detto tu, eh?



:-DDDDD



PS. Chi è quello che taglia quello che fa comodo?



-- 

Ciao!

Luca


 Ne dubito, dal momento che sia Google, che un bel po' di libri su Aspect Oriented Programming dicono l'esatto contrario di quel che hai scritto.



Quel che ti ostini a non capire è la mia affermazione è: c'entra poco con gli attributes. Voglio dire: i decorators in Python si adattano splendidamente alla AOP; non altrettando fanno gli attributes. In C# la cosa più vicina che ho trovato è (nomen omen) il Decorator pattern, che però si applica alle classi, non ai singoli metodi. Ho visto che esistono framework adeguati, ma non voglio usarli. Quindi, almeno finora, la risposta è: una cosa 'a la Python', altrettanto semplice e integrata nel linguaggio, non esiste.



-- 

Ciao!

Luca














E' un modo per dire che gli errori che mi impedisce di fare typescript 

non c'entrano nulla con gli unit test? E quindi significa che il culo 

coperto da typescript non è copribile con gli unit test e quindi che 

typescript è di fatto necessario per sviluppare decentemente con js?




 coperto da typescript non è copribile con gli unit test



No! Significa (e ti viene ripetuto per almeno la decima volta) che 

TypeScript non ti copre nessun culo. Il culo te lo coprono gli unit 

test. ANCHE se programmi in TypeScript devi ricorrere a unit test.

Uno dei tanti link sull'argomento:



https://visualstudiomagazine.com/articles/2013/06/01/test-driven-development-with-typescript.aspx




Vai su Google e inizia a studiare. Stai ripetendo cazzate da giorni, 

nonostante ti venga spiegato dove sbagli, e da parte mia questa e` 

l'ultima risposta.



-- 

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[...]" - 
http://goo.gl/1nrkkX



 l'ultima risposta.

Dai vediamo che rispondi a questo, è meglio:

1- js + unit test

2- typescript + unitest

La superficie scoperta di culo è con l'approccio 2 o 1?

Sentiamo...






Anche se si capisce lo stesso: la superficie scoperta di culo è minore 



Hai già detto che typescript senza unit test è meglio di js con unit test. E questa è una castronata.



Tutte le altre combinazioni (typescript vs js, typescript+test vs js, typescript+test vs js+test) non sono state oggetto di dibattito e non interessano a nessuno in questo thread. Se vuoi discuterne aprì un altro thread.




Oh, un altro a cui piace fare delle where mirate invece di considerare 

tutto il thread. Bravo.

Comunque scrivevo anche:

"

 > On Wednesday, 20 January 2016 20:07:11 UTC, AleTV  wrote:

 >

 > [...]

 >> I constraint che puoi usare con type script ti risolvono i problemi a

 >> monte, par facile come concetto.

 >

 > I constraint non ti riparano da bug di regressione. Mi par facile 

come concetto.

 >

Tu sviluppi in js via unit test? No, bene.

*** Manco io, uso type script che è meglio, molto meglio, di niente.  ***

"



Vedi che c'è scritto tra gli asterischi?

Comunque, giudice della corte, sentenza chiusa e mi dichiaro non 

colpevole... :-D




In questo thread l'hai pestata svariate volte, e non l'hai mai ammesso. 

Al massimo hai cominciato a mutare posizione quando ti sei accorto di avere la suola sporca, tuttavia sempre senza avere l'onestà di riconoscere l'errore.



Quindi inutile che ora vieni qua a smenarla.



Si certo, il bue che dice cornuto all'asino.




 Hai fatto una domanda stupida. Lo unit testing non e` materia di studio scientifico. Vorresti che ti citassi un articolo su Nature su cui i vari scienziati fanno peer review delle tecniche di testing? LOL :) La validita` di tutte le tecniche e metodologie che si adoperano in programmazione sono frutto di esperienza, a volte un'esperienza molto lunga. Quelle che ho riportato sono (una parte delle tante) conclusioni di fonti autorevoli, in campo informatico. Mi spiace, ma e` evidente che non hai esperienza a sufficienza per capire quel che sto dicendo. Se non sai che DrDobb's, ThoughtWorks e Kent Beck sono fonti autorevoli, il problema e` tuo.



Ma smettila di scimmiottare i tuoi idoli scrivendo cagate. Parecchi informatici di livello MONDIALE non adottano tdd e sparano fuori software certamente migliore di quello di andrea di it.politica.



Pero' secondo il conglioncello non sarebbe professionale! AHAHAH A HAHA


 Linguaggio più brutto: Java: pachidermico e prolisso.




 > Linguaggio più brutto: Java: pachidermico e prolisso.



Passa a questo allora:



https://it.wikipedia.org/wiki/Brainfuck