Quanto in profondità dovremmo immergerci per testare diversi livelli, ad esempio db_query di Drupal?

Question

Quanto in profondità dovremmo immergerci per testare diversi livelli, ad esempio db_query di Drupal?

#1 da (2 voti)
#2 da (0 voti)

4

Utilizziamo Drupal 7 come nostro strumento CMS di base.

Per uno specifico prodotto, qualcosa come un ERP, abbiamo creato una sorta di livello non drupal, per mantenere il nostro specifico codice aziendale.

Sarebbe qualcosa del genere:

-------------
|  Business | -> This would be our business specific code layer
-------------
|    Glue   | -> This is where we connect with the basic Drupal API as we need
-------------
|   Drupal  | -> This is Drupal API
-------------

Abbiamo il concetto di Repository , che è una classe base che recupera qualcosa dal database sotto forma di Entity o ArrayObject di Entities .

Questo layer è connesso a Drupal, dal momento che ha bisogno di accedere a metodo db_query () , dall'API Drupal 7 .

Il nostro intero Business layer è stato testato usando PHPUnit , con una copertura del 100%.

Ora stiamo provando a testare anche il livello Glue , l'unità di Repositories , i loro valori di ritorno e i parametri.

Per fare ciò, siamo giunti alla conclusione che dovremmo prendere in giro l'API di accesso al database Drupal .

Ma per farlo, quale sarebbe l'approccio corretto o migliore?

Avvolgi la funzione db_query da Drupal in una classe che potrebbe essere derisa nei test?
Non testare affatto Repositories ?

testing architecture mocking cms drupal

posta Daniel Ribeiro 21.12.2012 - 16:12

fonte

2 risposte

Leggi altre domande sui tag testing architecture mocking cms drupal

Microservizi e ruoli utente Memorizzazione di revisioni di un documento

score 2 · Answer 1

Bene, come in molti casi la risposta alla tua domanda inizia con ... "Dipende".

In primo luogo, dovresti chiederti "C'è qualche logica nel livello Deposito / Glue?" Voglio dire oltre ad adattarsi da e verso l'API D7. Se i repository, per esempio, hanno metodi che offrono un linguaggio di query personalizzato per trovare oggetti o set di oggetti specifici, metodi che selezionano e ordinano questi oggetti, allora probabilmente vorrai testare il Repository.

Il modo ideale per farlo sarebbe come hai suggerito, con una simulazione di una classe intermedia a db_query (). Ma prima di entrare in questo e iniziare a programmare, prenditi un minuto e pensa ai tuoi repository. Forse è accettabile testarlo con un vero database appositamente preparato con oggetti che conosci e in grado di controllarli a scopo di test. Trovo che la maggior parte delle volte queste parti del tuo progetto che cambiano molto raramente possano essere testate a questo livello più alto. Il test verrà eseguito un po 'più lentamente, ma forse puoi cavartela eseguendoli insieme ai test di funzionalità / integrazione che potresti avere sul tuo sistema. Dopotutto, l'intera cosa "colla" è per l'integrazione.

È anche possibile velocizzare i test con i database creando i database solo nella RAM o su un punto di montaggio che funge da ram-disk.

score 0 · Answer 2

Sulla base dei tuoi commenti aggiuntivi, personalmente non mi preoccuperei di prendere in giro qualsiasi classe per simulare l'API Drupal. Sembra che tu abbia progettato Glue per astrarre l'API Drupal un po 'dal livello Business, per renderlo più semplice da utilizzare.

Per fornire una copertura di prova ragionevole per la colla senza andare fuori bordo, potrei suggerire di fare alcuni test di base della scatola nera contro le chiamate API Drupal che intendi utilizzare per assicurarti che funzionino come previsto. Avrai fiducia che l'API Drupal sta facendo ciò che è previsto e che stai integrando con un'API funzionante. Quindi dovresti testare insieme la colla e l'API Drupal. Dopo aver definito i test e averli eseguiti in modo soddisfacente, considererei la colla sufficientemente testata.

In base a questo approccio, poiché non intendi utilizzare Glue con altre API diverse da Drupal, penso che avrai testato Glue in modo adeguato senza masterizzare cicli aggiuntivi, creando più lavoro per te stesso del necessario.