Studiare le basi della programmazione ad oggetti.

Grazie ad Antonio per questi spunti.

Annunci

Extreme Enthusiasm » Blog Archive » When refactoring is no use.

Scrum Case Studies | Agile Pain Relief.

Dr Dobbs – Embedded Agile: A Case Study In Numbers.

Replace conditional with….

…by Luca Minudel!

Extreme Enthusiasm » Blog Archive » The OCP kata.

Three Rivers Institute » Blog Archive » TDD is Kanban for Code.

Ci sono parecchi framework per il testing di codice javascript in giro ma la maggior parte richiedono un browser per poter eseguire i test.
Dato che ho necessità di testare delle classi che utilizzo per scriptare Photoshop ne ho dovuto cercare uno che potesse funzionare anche senza browser.

La scelta è caduta su jsUnity.
Purtroppo non ho potuto utilizzarlo così com’è ma è stato necessario fare qualche piccola modifica per farlo funzionare correttamente.

In particolare ho dovuto modificare il metodo splitFunction in questo modo:

function splitFunction(fn) {
var fnSource = fn.toSource();
var re = 0;
re = new RegExp();
var regExString = “”;

regExString = “^\\(function\\s*([^\\(\\s]*?)\\s*\\(.*\\)”;
re.compile(regExString);
var tokens = re.exec(fnSource);

if (!tokens) {
throw “Invalid function.”;
}
var fnName = tokens[1].length ? tokens[1] : undefined;

regExString = “\\s?\\{(.*)\\)?\\}\\)?$”;
re.compile(regExString);
var tokens = re.exec(fnSource);
if (!tokens) {
throw “Invalid function.”;
}

var fnBody = tokens[1];
return {
name: fnName,
body: fnBody
};
}

So che la regular expression per estrazione del codice è abbastanza diversa da quella usata nel codice originario ma al momento non ho notato effetti collaterali nella mia modifica.

Dopo averci penato su un po’ di ore sono riuscito a scrivere un paio di test che sfruttano la simulazione di eventi di mouse.

Probabilmente se la nostra applicazione si limitasse ad usare oggetti derivati da QWidget tutto sarebbe andato liscio al primo colpo ma sarebbe stato troppo facile 😀

Tutti il nostro framework si basa infatti su oggetti completamente custom quindi l’approccio documentato non si può seguire completamente. Ho dovuto quindi modificare questo file h per poter gestire anche eventi di tipo QGraphicsSceneMouseEvent.
Per fortuna non è stato difficile: ho aggiunto un altro metodo statico analogo a quello esistente che accetta un QObject anzichè un QWidget e fatto qualche altra modifica per inviare i messaggi di tipo adatto (QGraphicsSceneQUALCOSAEvent).

La parte rognosa è stato convincere il mio oggetto a gestire gli eventi simulati che gli mandavo. L’unico modo che ho trovato è stato di fare implementare il metodo Event() per la classe base da cui derivano i nostri oggetti grafici.

Non sono sicuro che sia il modo corretto di procedere ma la mia conoscenza del framework è al momento troppo superficiale per fare di più. Mi riservo di chedere lumi alla community QT: ho idea che non sono in tanti ad aver provato a scrivere test su questi oggetti.
Per fortuna non mi spaventa percorrere strade (relativamente) nuove! 😉

Oggi ho scoperto che le QT hanno un proprio framework di test.
Dato che i progetti su cui sto lavorando ultimamente si basano proprio su questo framework grafico ho provato a fare qualche prova per poter valutare se vale la pena proporne l’adozione al mio gruppo di lavoro.

Devo dire che è stato abbastanza semplice scrivere un test banale e questo mi ha piacevolmente sorpreso dato che mi aspettavo un setup complesso del progetto.

Per avere un’idea di ciò che c’è da fare si può dare uno sguardo qui dove viene mostrato del codice preso dalla documentazione ufficiale online. Esiste anche una funzionalità analoga al rowtest di MBUnit! 😀

Appena possibile verificherò anche le funzionalità di test più orientate all’interazione con la gui e il supporto ai benchmark (da non trascurare in ambente embedded).

I miei bookmark

Timeline