Il titolo è un po’ crip­tico, lo so! Cominciamo quindi con il defi­nire i ter­mini della que­stione, in par­ti­co­lare per il con­cetto di “Singolarità”.

Per Singolarità – o, più pre­ci­sa­mente, Singolarità Tecnologica (ST) – si intende grosso modo il momento in cui, gra­zie ai pro­gressi tec­no­lo­gici, sarà pos­si­bile creare un’intelligenza supe­riore a quella umana. Dico “grosso modo” per­ché in realtà sono state date diverse defi­ni­zioni di que­sto con­cetto, tutte di sapore più o meno pro­fe­tico e misticheggiante.

James Bach (il “col­lau­da­tore” del titolo), in que­sto post, getta un bel po’ di acqua sul fuoco, met­tendo in rilievo tutta una serie di appros­si­ma­zioni che ren­dono tutta la que­stione molto meno ecci­tante. Ad esem­pio, non siamo in grado nem­meno di defi­nire l’intelligenza: come potremo sapere di averla supe­rata? La pre­vi­sione di Bach è che il rag­giun­gi­mento della ST verrà vani­fi­cato dalla sua cre­scente com­ples­sità e fragilità.

Ho sem­pre pen­sato che il fat­tore limi­tante della com­ples­sità fosse quello più “pesante”. Tuttavia, oggi ne sono meno sicuro: non ci sarà una tra­su­ma­na­zione come quella sognata dai futu­ro­logi ma credo che anche uno – giu­sta­mente – scet­tico come Bach sarà sor­preso dei pro­gressi che saranno stati fatti.

Anche se sono mesi che non apro Eclipse, le novità dell’ultima ver­sione di JUnit sono ben­ve­nute. Ad es. adesso, al pari di altri fra­meworks – JMock, se non ricordo male – è pos­si­bile scri­vere cose del tipo:

assertThat(x, is(3));
assertThat(x, is(not(4)));
assertThat(responseString, either(containsString("color"))
    .or(containsString("colour")));
assertThat(myList, hasItem("3"));

Altra aggiunta utile e, soprat­tutto, che può cam­biare l’approccio ad alcuni sce­nari di test è la pos­si­bi­lità di espli­ci­tare gli assunti rite­nuti validi durante lo sviluppo:

assertThat(x, is(3));
@Test public void filenameIncludesUsername() {
       assumeThat(File.separatorChar, is('/'));
       assertThat(new User("optimus").configFileName(),
           is("configfiles/optimus.cfg"));
}

Ad oggi que­sti assunti non fanno fal­lire il test se si rive­lano falsi.

Per esten­sione sono state intro­dotte le teo­rie. Ad es:

assertThat(x, is(3));
@RunWith(Theories.class)
public class UserTest {
  @DataPoint public static String GOOD_USERNAME = "optimus";
  @DataPoint public static String USERNAME_WITH_SLASH = "optimus/prime";

  @Theory public void filenameIncludesUsername(String username) {
    assumeThat(username, not(containsString("/")));
    assertThat(new User(username).configFileName(),
        containsString(username));
  }
}

La teo­ria espressa da filenameIncludesUsername viene veri­fi­cata per ogni @DataPoint e il test fal­li­sce se, per un @DataPoint che con­ferma l’assunto, l’asserzione è falsa.

Grazie ai data point è ora pos­si­bile scri­vere test su insiemi in maniera più natu­rale; TestNG rimane ancora avanti in que­sto set­tore ma la distanza si è accorciata.

Fino ad ora non avevo tro­vato un modo sod­di­sfa­cente di scri­vere le user sto­ries e/o i cri­teri per i test di accet­ta­zione. Con le user sto­ries, in par­ti­co­lare, la dif­fi­coltà era sem­pre quella legata alla loro “ampiezza”.

Il for­mato che ho tro­vato mi sem­bra sod­di­sfa­cente – quan­to­meno è un ini­zio, no? –. Per le user stories è:

• Come <ruolo>
• Voglio que­sta <possibilità<
• In modo che <beneficio>
• E/o non <com­por­ta­mento indesiderabile>

Per i test di accet­ta­zione, invece:

• Dato <con­te­sto>
• Quando <azioni compiute/eventi accaduti<
• Allora <risul­tato voluto>
• Invece di <risul­tato ottenuto>

Articolo ori­gi­nale

Se volete fare una rapida veri­fica della qua­lità della vostra con­nes­sione xDSL, Speedtest.net può esservi utile.

Il numero dei com­po­nenti da sca­ri­care in una pagina è il para­me­tro che più influenza i tempi di sca­ri­ca­mento della pagina.

L’HTTP/1.1 sug­ge­ri­sce di sca­ri­care al mas­simo due com­po­nenti in paral­lelo per ogni host­name e que­sto implica che, se vogliamo miglio­rare i tempi di sca­ri­ca­mento di una pagina aumen­tando il grado di paral­le­li­smo, dob­biamo ser­vire i com­po­nenti di una pagina da più host.

I test con­dotti da Yahoo! sem­brano indi­care che il numero otti­male di down­load paral­leli è 4, otte­nuto con due alias, ovvero, due host­name alter­na­tivi in aggiunta al prin­ci­pale, da cui viene sca­ri­cata la pagina.

Bella defi­ni­zione di Brian Marick, su che cos’è l’attitudine all’agilità:

The Agile atti­tude is shown by doing a lit­tle less than the mini­mum you can ima­gine wor­king, then let­ting rea­lity drive you to add more pro­cess, tech­no­logy, or wha­te­ver. It’s much easier to add when you’ve done too lit­tle than remove when you’ve done too much. (I think I lear­ned this from either Alistair Cockburn or Jim Highsmith #.

Una robu­sta rete di sicu­rezza for­nita dai test è essen­ziale per poter intra­pren­dere il refac­to­ring del codice.

Spesso, però, que­sti test diven­tano essi stessi fonte di rigi­dità e di dupli­ca­zione di codice. A volte può non essere un pro­blema ma può anche ren­dersi neces­sa­ria la loro riscrit­tura… ma non abbiamo dei test sui test! Che fare?

L’idea di base di que­sto arti­colo è quella di usare le modi­fi­che al codice testato che cau­sano dei fal­li­menti attesi nei test, come indi­ca­tori della bontà dei refac­to­ring dei test.

Spinto dalla neces­sità di testare delle pro­ce­dure di migra­zione di un data­base, ho pen­sato bene di fare una sma­net­tata con  TestNG. Beh, direi che è una manna dal cielo!!

Ci sono diverse cose che a mio parere ren­dono TestNG net­ta­mente migliore di JUnit:

• Un set di anno­ta­zioni più esteso
• È molto più fles­si­bile nel clas­si­fi­care i test
• È pos­si­bile sta­bi­lire delle dipen­den­denze fra i test
• È con­fi­gu­ra­bile tra­mite file
• È pos­si­bile ripe­tere lo stesso test con un set di dati a pia­cere. I dati pos­sono essere pas­sati dalle con­fi­gu­ra­zioni o dai @DataProvider. Con que­sta anno­ta­zione ho potuto auto­ma­tiz­zare i test in modo molto più esaustivo.
• Di default, TestNG ri-esegue solo i test fal­liti dal lan­cio precedente

Credo che basti a far venire un po’ di appe­tito… Altri links:

• JUnit vs TestNG: un con­fronto fra i due frameworks
• Statistical testing: uso di TestNG in sce­nari dif­fi­cil­mente testa­bili da JUnit

Dopo il post sui nume­rici “magici”, eccone un altro sulle strin­ghe da usare per testare i campi di testo:

• Nomi con il trat­tino breve, ad es. Mario Rossi–Verdi.
• Nomi che ini­ziano con O’. In ambito ita­liano que­sto non è molto utile. Forse si potrebbe sosti­tuire con D’, come D’Angelo.
• Nomi lun­ghi: spesso il limite dei campi per i nomi è impo­stato a 20 e non sem­pre è suf­fi­ciente. Per ren­dere più agen­vole la veri­fica delle strin­ghe con la lun­ghezza mas­sima con­sen­tita non ven­gano tron­cate, si può usare un “!”.
• Caratteri “spe­ciali”
• Codifiche html e/o esadecimali
• Stringhe SQL