Tips

Accedere ad un database sqlite con Ruby

Antonio Ganci — Mon, 02 Jan 2012 19:04:40 GMT

In questo post vedremo come accedere ad un database sqlite utilizzando Ruby. La scelta di sqlite è dovuta alla sua estrema semplicità di gestione, in quanto il database consiste in un unico file. Per prima cosa occorre installare una libreria per poterlo utilizzare da ruby. Basta digitare da terminale gem install sqlite3-ruby. Ora creiamo il file sqlite-test.rb con il seguente contenuto: require 'sqlite3' require 'test/unit' class DatabaseTest < Test::Unit::TestCase def setup @db = SQLite3::Database.new 'test.db' end def teardown @db.close end def test_create assert File.exist? 'test.db' end end Come si puo' vedere dal test il database consiste in un unico file test.db creato nella stessa directory. Se lanciamo il test abbiamo barra verde. Proviamo ora a creare una tabella e ad inserire alcuni dati. Aggiungiamo quindi il test: def test_create_table sql = <<SQL create table names ( id int primary key, name text ); SQL @db.execute sql assert_equal @db.execute('select * from names'), [] end Proviamo a lanciarlo: Barra verde. Se proviamo però a rilanciarlo otteniamo l'errore: SQLite3::SQLException: table names already exists. Per risolvere il problema cancelliamo la tabella, se esiste, prima di crearla utilizzando il comando: drop table if exists names;. Un'altra alternativa potrebbe essere la cancellazione del file di database. def test_create_table sql = <<SQL drop table if exists names; create table names ( id int primary key, name text ); SQL @db.execute_batch sql assert_equal @db.execute('select * from names'), [] end Notare che ho modificato execute con execute_batch perché altrimenti sarebbe stata eseguita solo una delle due query. A questo punto siamo pronti per inserire alcuni dati e verificare che siano presenti nella tabella def test_create_table sql = <<SQL drop table if exists names; create table names ( id int primary key, name text ); insert into names values(1, 'a'); insert into names values(2, 'b'); SQL @db.execute_batch sql assert_equal @db.execute('select * from names'), [[1, 'a'], [2, 'b']] end Come si puo' leggere dal test i dati vengono restituiti come un array di array. Altre informazioni su come usare sqlite le potete trovare qui

Sviluppare un sito web in TDD usando Ruby e Sinatra

Antonio Ganci — Wed, 28 Dec 2011 18:30:11 GMT

In questo post illustrerò un modo per sviluppare un sito web che usa Sinatra usando la pratica del TDD. Per poter provare gli esempi occorre aver seguito i passi del mio precedente post. Sinatra, come altri framework scritti in Ruby, aderisce allo standard Rack. In sintesi basta realizzare un oggetto che risponde al messagio call, prende un hash come parametro e risponde con un vettore di tre elementi: lo status code, l'header http e il body. Un esempio di un oggetto che rispetta lo standard è: class HelloWorld def call(env) [200, {"Content-Type" => "text/plain"}, ["Hello world!"]] end end Questo ha il vantaggio di avere degli oggetti già pronti per poter scrivere i test. Prima occorre da terminale eseguire il comando: gem install rack-test in modo da installare tutto ciò che ci serve. A questo punto siamo pronti a scrivere il nostro primo test (il file l'ho chiamato sitetest.rb): require './site' require 'test/unit' require 'rack/test' class SiteTest < Test::Unit::TestCase def test_homepage browser = Rack::Test::Session.new(Rack::MockSession.new(Sinatra::Application)) browser.get '/' assert browser.last_response.ok? end end Creiamo anche il file (site.rb) dell'applicazione che per ora non ha impostato nessun routing: require 'sinatra' Se ora lanciamo il test con il comando ruby sitetest.rb. Vediamo che l'assert fallisce. Il codice minimo per la barra verde è: require 'sinatra' get '/' do end Rilanciamo il test ed ecco la prima barra verde! A questo punto vogliamo che la nostra pagina abbia il contenuto Hello World. Aggiungiamo quindi un assert: assert_equal browser.last_response.body, 'Hello World' Lanciamo nuovamente il test ed otteniamo il messaggio: 1) Failure: test_homepage(SiteTest) [sitetest.rb:13]: <""> expected but was <"Hello World">. Modifichiamo il codice di produzione per la barra verde: require 'sinatra' get '/' do 'Hello World' end Alcune note: Affinchè un metodo venga eseguito dal test runner deve iniziare per test Sinatra::Application è l'oggetto che rispetta lo standard rack Maggiori dettagli su come scrivere i test usando Rack e Sinatra sono qui Buon divertimento.

Ridurre la complessità del sistema implementando un interfaccia in modo esplicito

Antonio Ganci — Wed, 07 Dec 2011 20:32:15 GMT

Un collega mi ha suggerito una tecnica interessante quando si è in presenza di codice legacy. Nella nostra codebase abbiamo creato l'astrazione ICommitCommand per modificare i dati delle risorse esterne nei setup dei un test di accettazione in cui utilizziamo i sistemi reali e non dei fake. Nel caso specifico la scrittura su un indice di Lucene e la modifica di alcuni dati nel db. interface ICommitCommand { void Execute(); } Inizialmente avevo creato l'oggetto: class LuceneCommand : ICommitCommand { LuceneClient _client; public LuceneCommand(LuceneClient client) { _client = client; } public void Execute() { _client.Update(); } } LuceneCommand è un adapter per l'interfaccia ICommitCommand. Il problema dell'oggetto è che soffre dello smell Lazy Class (cioè una classe che fa troppo poco). Un modo per risolverlo è quello di fare implementare l'interfaccia direttamente a LuceneClient. Purtroppo il metodo Execute non ha molto significato per LuceneClient. La soluzione che abbiamo adottato è quella di farlo implementare in modo esplicito: class LuceneClient : ICommitCommand { ... void ICommitCommand.Execute() { _client.Update(); } ... } In questo modo se utilizzo direttamente LuceneClient non posso chiamare il metodo Execute, mentre se ne ho un riferimento come ICommitCommand posso chiamare il metodo. Questa tecnica viene sfruttata anche nel .net framework per l'oggetto Dictionary che implementa il metodo Add(KeyValuePair) privatamente: var dictionary = new Dictionary<int, string>(); dictionary.Add(new KeyValuePair<int, string>()); // Error var d = (IDictionary<int, string>) dictionary; d.Add(new KeyValuePair<int, string>()); // ok Il vantaggio di questa soluzione è che riduce la complessità del sistema, evitando il proliferare di adapter che non fanno altro che permettere ad una classe di implementare l'interfaccia desiderata.

Test automatico per verificare che l'html non contenga errori

Antonio Ganci — Mon, 28 Mar 2011 15:53:18 GMT

Dopo che ci è scappato un errore nell'html del sito su cui stiamo lavorando, abbiamo deciso di scrivere un test che validi l'html prodotto. Per raggiungere l'obiettivo utilizziamo l'utility Tidy che si puo' scaricare da qui È un piccolo eseguibile a cui si puo' passare un html e verificare che non contenga errori. Il codice del test è piuttosto semplice: [Test] public void ValidateHtml() { var html = new WebClient().DownloadString(@"http://someurl.com"); process = new Process(); process.StartInfo.FileName = "tidy.exe"; process.StartInfo.Arguments = "-e"; process.StartInfo.UseShellExecute = false; process.StartInfo.CreateNoWindow = true; process.StartInfo.RedirectStandardError = true; process.StartInfo.RedirectStandardInput = true; process.Start(); process.StandardInput.Write(html); process.StandardInput.Close(); process.WaitForExit(); Assert.That(_process.ExitCode, Is.EqualTo(0), _process.StandardError.ReadToEnd()); } Il processo viene creato redirigendo lo standard input e lo standard error, il primo usato per inviare l'html, mentre il secondo come messaggio di errore nel caso l'Assert fallisca. L'output di tidy è piuttosto esplicativo e ci permette di correggere velocemente gli errori individuati. l'opzione -e indica di mostrare solo gli errori, altrimenti tidy puo' anche provare a correggerli, opzione che non utilizziamo. La documentazione sulle opzioni supportate da tidy la trovate qui.

Accedere ad un field pubblico da un metodo privato in Javascript

Antonio Ganci — Mon, 14 Feb 2011 15:48:41 GMT

Oggi mi sono imbattuto in un problema imprevisto e voglio condividerlo perché potrebbe tornare utile a chi non padroneggia Javascript. Supponiamo di avere un oggetto definito come segue: function AnObject() { this.value = 1000; var set_value = function(new_value) { this.value = new_value; }; this.start = function() { set_value(5); } } L'oggetto ha un field pubblico chiamato value, un metodo pubblico chiamato start ed un metodo privato chiamato set_value. Supponiamo ora che vogliamo testarlo ed il test sia il seguente: function an_object_test() { test("an object", function() { var obj = new AnObject(); obj.start(); equal(obj.value, 5); }); } Il test sarà passerà o fallirà? Se lo eseguiamo otterremo una soprendente barra rossa, con il messaggio: Expected 5 but was 1000, come se il metodo privato non fosse stato eseguito. Per quale motivo? Il this nel metodo privato non si riferisce all'oggetto AnObject, piuttosto all'oggetto globale del browser window. Questo problema è spiegato nel post Private Members in JavaScript di Douglas Crockford. In particolare la soluzione proposta è: function AnObject() { this.value = 1000; var that = this; var set_value = function(new_value) { that.value = new_value; }; this.start = function() { set_value(5); } } Il motivo del field that è spiegato nel post: By convention, we make a private that variable. This is used to make the object available to the private methods. This is a workaround for an error in the ECMAScript Language Specification which causes this to be set incorrectly for inner functions. Tenetelo presente quando lavorate in Javascript perché potrebbe riservare spiacevoli sorprese.

Scrivere test automatici per Javascript - parte 3

Antonio Ganci — Fri, 11 Feb 2011 15:56:53 GMT

Prima di proseguire consiglio la lettura della prima parte e della seconda parte. In questo post affronteremo l'argomento dei mock object. Una prima tentazione potrebbe essere quella di cercare una libreria di mock per Javascript, ma vista la sua natura dinamica proviamo a farne a meno. Partiamo da un esempio per introdurre l'argomento. Supponiamo di voler testare il seguente metodo: function show_alert(text) { alert(text); } Ovviamente se eseguiamo tale metodo vedremo comparire una message box. Vediamo se riusciamo a testare l'interazione. Per prima cosa occorre che quando viene chiamato alert venga eseguita una function nostra e non quella standard. Occorre anche che quando il test termina l'esecuzione, venga ripristinata la vecchia function. test("show alert", function() { var old_alert = alert; alert = function() { }; show_alert('Ciao!'); alert = old_alert; }); Se proviamo ad eseguire il metodo di test in QUnit vedremo che non viene più visualizzato l'alert. In quanto abbiamo sostituito alert con una function vuota. Questo a noi non basta perché vogliamo testare che venga chiamato alert con un certo parametro una sola volta. Aggiungiamo quindi del comportamento al nostro mock. test("show alert", function() { var old_alert = alert; var alert_call_count = 0; alert = function() { alert_call_count++; }; show_alert('Ciao!'); equals(alert_call_count, 1); alert = old_alert; }); Il test sta diventando illegibile, facciamo un primo passo portando il codice di setup nel setup del modulo. In QUnit si possono dichiarare dei moduli che assomigliano agli attributi Setup e TearDown delle Fixture di NUnit. Ecco un esempio di dichiarazione di modulo con i metodi setup e teardown: module("module name", { setup: function() { // setup code }, teardown: function() { // teardown code } }) Proviamo ad applicare il concetto appena esposto al test precedente: var old_alert; var alert_call_count = 0; module("show alert", { setup: function() { old_alert = alert; alert_call_count = 0; alert = function() { alert_call_count++; }; }, teardown: function() { alert = old_alert; } }) test("show alert", function() { show_alert('Ciao!'); equals(alert_call_count, 1); }); Il test si è accorciato notevolmente, ma se abbiamo mock più complicati il codice del setup diventerebbe presto molto complicato. La logica precedente comunque si puo' estrarre un oggetto Mock in modo da semplificare la scrittura dei test. Per testare il parametro passato si puo' procedere in maniera simile basta salvarsi il valore in una variabile e poi fare la assert su quel valore.

Scrivere test automatici per Javascript - parte 2

Antonio Ganci — Tue, 08 Feb 2011 15:54:38 GMT

Nello scorso post ho descritto come scrivere test automatici per Javascript. Uno degli svantaggi della soluzione proposta sta nel ricordarsi di chiamare le function di test. Infatti se guardiamo il codice della pagina html: $(document).ready(function(){ sum_test(); }) Vediamo la chiamata a sum_test che contine il test. Se abbiamo molti di questi metodi la manutenzione dell'elenco puo' diventare piuttosto noiosa e error-prone. Una soluzione è quella di creare un oggetto Javascript che esegua automaticamente tutte le function che terminano per _test. In Javascript esiste l'oggetto globale window il quale contiene, tra le altre cose, tutte le function definite dall'utente. Abbiamo quindi sfruttato questa caratteristica per realizzare un test runner di cui riporto il codice. function TestRunner(filter) { var test_filter = filter; this.run = function() { var tests = test_filter.select_all(); for (var test_index in tests) { tests[test_index](); } } } var TestFilter = function(test_container) { var container = test_container; this.select_all = function(){ var properties = get_all_accessible_properties(); return select_test_functions(properties); }; var get_all_accessible_properties = function() { var result = []; for (var property_name in container) { if(is_property_accessible(property_name)) { result.push(container[property_name]); } } return result; }; var select_test_functions = function(properties) { var result = []; for (var property_index in properties) { var property = properties[property_index]; if(is_test_function(property)) { result.push(property); } } return result; }; var is_property_accessible = function(property_name) { try { container[property_name]; return true; } catch(exc) { return false; } }; var is_test_function = function(property) { return typeof property === 'function' && property.toString().indexOf('_test()') >= 0; } }; Per invocare i test basta sostituire la precedente chiamata a sum_test con: new TestRunner(new TestFilter(window)).run(); Una cosa interessante del codice precedente è che mostra una tecnica (non l'unica possibile) per definire gli oggetti in Javascript. Prendiamo ad esempio il TestRunner. Il codice: function TestRunner(filter) { } Definisce un oggetto chiamato TestRunner con un costruttore con un parametro. Il quale si puo' instanziare con una sintassi molto simile al C# new TestFilter(someParameter) All'interno dell'oggetto si possono definire dei field privati. Nel nostro caso aggiungiamo il field test_filter inizializzato con il valore passato dal costruttore: function TestRunner(filter) { var test_filter = filter; } A questo punto possiamo aggiungere un metodo pubblico: function TestRunner(filter) { var test_filter = filter; this.run = function() { // do something } } } Per i metodi privati la tecnica è analoga con l'unica differenza di mettere var al posto di this. come si vede per l'oggetto TestFilter. Rimane un ultimo problema da risolvere. Se un test di QUnit solleva un'eccezione non vedo la barra rossa. Per evitare questa mancanza possiamo modificare il codice precedente con questo: <script type="text/javascript"> $(document).ready(function() { try { new TestRunner(new TestFilter(window)).run(); } catch (e) { module("Fatal errors"); test("Exception thrown by running tests", function() { ok(false, 'Message: ' + e.message + ' -- StackTrace: ' + e.stack); }); } }); A questo punto siamo pronti per scrivere i nostri test e vederli eseguiti all'interno del browser. Buona barra verde!

Scrivere test automatici per Javascript

Antonio Ganci — Tue, 08 Feb 2011 09:47:05 GMT

Ultimamente sto lavorando con il linguaggio Javascript. All'inizio ho avuto qualche difficoltà, perché la sintassi è molto lontana da quella dei linguaggi con cui ho sviluppato in passato o sviluppo abitualmente (C#, C++, Java), ma con il tempo ha iniziato a piacermi, soprattutto per la semplicità e potenza espressiva. L'attività che sto svolgendo è la copertura di test di codice esistente e un refactoring per migliorarne la leggibilità, in modo da poter aggiungere funzionalità limitando la probabilità di regressioni. Per i test automatici utilizziamo QUnit. Vediamo un esempio. Supponiamo di avere il file sum.js con il seguente metodo da testare: function sum() { var total = 0; for(var arg in arguments) { total += arguments[arg]; } return total; } arguments è una variabile di Javascript che contiene i parametri passati alla function. In pratica viene fatta la somma dei parametri passati. Partiamo dal test che dimostra che senza parametri la somma sia zero. Il test lo scriviamo nel file sum-test.js. function sum_test() { test("sum without arguments is zero", function() { equals(sum(), 0); }); } la function test e equals sono definiti in QUnit. A questo punto creiamo una pagina html che permetta di eseguire il nostro test: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" > <head> <script type="text/javascript" src="http://code.jquery.com/jquery-latest.js"></script> <link rel="stylesheet" href="http://code.jquery.com/qunit/git/qunit.css" type="text/css" media="screen" /> <script type="text/javascript" src="http://code.jquery.com/qunit/git/qunit.js"></script> <script type="text/javascript" src="sum.js"></script> <script type="text/javascript" src="sum-test.js"></script> <script type="text/javascript" > $(document).ready(function(){ sum_test(); }) </script> <title>Test</title> </head> <body> <h1 id="qunit-header">QUnit example</h1> <h2 id="qunit-banner"></h2> <div id="qunit-testrunner-toolbar"></div> <h2 id="qunit-userAgent"></h2> <ol id="qunit-tests"></ol> <div id="qunit-fixture">test markup, will be hidden</div> </body> </html> Se apriamo la pagina l'output sarà simile a: Dalla quale si puo' vedere il test che ha girato. Una cosa interessante è che QUnit mostra il numero delle assert eseguite non solo dei test.

Togliere la dipendenza circolare tra due oggetti

Antonio Ganci — Sat, 18 Sep 2010 18:38:41 GMT

Supponete di avere due oggetti uno di tipo A e l'altro di tipo B, dove A chiama un metodo di B e viceversa. In pratica esiste una dipendenza circolare tra i due oggetti (il discorso si puo' ampliare facilmente ad n oggetti). Proviamo a visualizzare tale interazione con un communication diagram (ne avevo già parlato in questo post). Come vedete dal disegno il refactoring risulta molto semplice da capire. In pratica creiamo un nuovo oggetto di tipo C che chiama gli oggetti di tipo A e tipo B ed in questo modo abbiamo tolto la referenza circolare. Non so se esiste già da qualche parte tale refactoring che battezzo: Remove circular dependency.

Un tecnica per testare l'interazione tra oggetti

Antonio Ganci — Mon, 06 Sep 2010 09:54:57 GMT

Ogni tanto, nello sviluppo software, emerge qualche meme come ad esempio: tutte le dipendenze devono essere disaccoppiate tramite un interface, tutte gli oggetti devono essere creati tramite factory, l'accesso ad un database deve avvenire tramite un ORM, il TDD genera un buon design ecc. Cosa hanno in comune tutte le frasi precedenti? Semplice: creano scorciatoie per evitare di pensare. Sarebbe bello se potessimo scrivere codice seguendo alla lettera un manuale, ma sarebbe anche terribilmente noioso e probabilmente verremmo sostituiti da qualche tipo di bot. Prendiamo la prima affermazione: tutte le dipendenze devono essere disaccoppiate tramite un interface e cerchiamo di capire da dove nasce questa esigenza. Il vantaggio di avere le dipendenze solo tramite interfacce dovrebbe essere quello di rendere più testabile le nostre classi. Ma è l'unico modo? Ed è il più semplice? Proviamo a fare un esempio. Supponiamo di voler testare il metodo SayHello: var display = new Display(); var greeting = new Greeting(display); greeting.SayHello(); L'implementazione di Greeting è la seguente: public class Greeting { private readonly Display _display; public Greeting(Display display) { _display = display; } public void SayHello() { _display.Show("Hello!"); } } Mentre l'implementazione di display è la seguente: public class Display { public void Show(string text) { Console.WriteLine(text); } } Sembra proprio il tipico esempio da manuale in cui si estrae l'interfaccia IDisplay e tramite la libreria di mocking preferita testo le interazioni di Greeting con Display. Esiste un'alternativa? La classe Console eredita da TextWriter, anche la classe StringWriter eredita da TextWriter. Proviamo quindi a passare la Console in costruzione a Display: public class Display { private readonly TextWriter _textWriter; public Display(TextWriter textWriter) { _textWriter = textWriter; } public void Show(string text) { _textWriter.WriteLine(text); } } Ora modfichiamo il main: var display = new Display(Console.Out); var greeting = new Greeting(display); greeting.SayHello(); A questo punto possiamo scrivere il test: var stringWriter = new StringWriter(); var greeting = new Greeting(new Display(stringWriter)); greeting.SayHello(); Assert.That(stringWriter.ToString(), Is.EqualTo("Hello!")); In questo modo abbiamo fatto un test più solido rispetto a testare l'interazione con un interfaccia ed il codice è più semplice.