««« | »»»

Test-driven design con PostgreSQL: pgTAP

Fino ad ora ho sem­pre testato il data­base attra­verso un qual­che stru­mento esterno, come i vari JUnit, TestNG o tcl­test.

Sono libre­rie che fun­zio­nano bene e che sono fami­liari a chiun­que pra­ti­chi un minimo di TDD ma non par­ti­co­lar­mente tagliate per testare i data­base (con l’eccezione forse di TestNG, che non uso da anni): vuoi per­ché biso­gna pre­ve­dere delle fix­ture ela­bo­rate che vanno poi eli­mi­nate; vuoi per­ché, a ben guar­dare, biso­gna attra­ver­sare tutta una serie di strati soft­ware anche solo per veri­fi­care un constraint.

Così ho fatto una ricerca e ho tro­vato due uti­lità per PostgreSQL — pgTAP e PGUnit — che per­met­tono di creare delle suite di test ese­guite diret­ta­mente nel database.

I van­taggi sono diversi: oltre all’accesso più diretto e pre­sta­zioni pre­su­mi­bil­mente migliori, la gestione delle fix­ture risulta sem­pli­fi­cata per­ché basta fare il roll­back alla fine dei test; inol­tre, dato che in PostgreSQL i comandi DDL sono tran­sa­zio­nali, diventa pos­si­bile testare le modi­fi­che al data­base istan­ta­nea­mente, senza doverlo fare in modo permanente.

Per ora ho scelto pgTAP. Mette a dispo­si­zione una serie di fun­zioni che pos­sono venire molto comode per scri­vere i test.

Le prime impres­sioni sono buone e penso che il miglio­ra­mento sarà anche più mar­cato quando potrò dise­gnare diret­ta­mente da zero uno schema in moda­lità TDD.

Per proseguire

Commenti e trackback sono disabilitati.

• Tweets, 2012-05-20
• Tweets, 2012-05-13
• Tweets, 2012-05-06
• Tweets, 2012-04-29
• Tweets, 2012-04-22