"Test unità" un report

Question

In che modo si "testare" un report creato da un motore di report come Crystal Reports o SQL Server Reporting Services?

Answer 1

Il problema con i rapporti è simile al problema con le GUI. Se il Report/GUI ha molta intelligenza (mal riposta) renderà difficile il test. La soluzione è quindi di

• Separated Presentation: presentazione separata dal contenuto (regole di accesso ai dati/domain/business). Nel contesto corrente significherebbe creare una sorta di classe ViewModel che rispecchia il contenuto del report finale (ad esempio se si dispone di dettagli dell'ordine e di elementi nel report, questa classe dovrebbe avere proprietà per i dettagli e un elenco di righe oggetto oggetti). ViewModel è infinitamente più semplice da testare. L'ultimo miglio, applicando la presentazione al contenuto dovrebbe essere relativamente banale (interfaccia utente sottile).
  ad es. se si utilizza xslt per eseguire il rendering dei report, è possibile testare i dati xml utilizzando strumenti come XmlUnit o stringa di confronto. Puoi ragionevolmente fidarti delle trasformazioni xsl sul data xml per il rapporto finale ... Inoltre, qualsiasi bug qui presente sarebbe banale da risolvere.
• Tuttavia, se si utilizzano fornitori di terze parti come Crystal Reports, non si ha alcun controllo/accesso per la creazione del report.In questi casi, il meglio che puoi fare è generare file di output rappresentativi/previsti (ad esempio pdf) denominati Golden Files. Utilizzalo come risorsa di sola lettura nei tuoi test per confrontare l'output effettivo. Tuttavia questo approccio è molto fragile ... in quanto qualsiasi modifica sostanziale al codice di generazione del report potrebbe rendere scorretti tutti i precedenti file golden. Quindi dovrebbero essere rigenerati. Se il rapporto costo/benefici dell'automazione è troppo alto, direi Vai a manuale con i piani di test dei doc di parole vecchia scuola.

Answer 2

Il meglio che posso pensare, sta confrontando i risultati con un risultato atteso.

Forse qualche intelligenza può essere aggiunta, ma non è così facile testare questi grandi blocchi.

Answer 3

Sono d'accordo con Gamecat.

Generare il report da dati fissi (costanti) e confrontarlo con l'output previsto per tali dati.

Dopo di che si potrebbe essere in grado di utilizzare i test semplici come diff (verificare se i file sono identici)

Answer 4

Per testare il nostro proprio prodotto di reporting basata su Java, i-net Clear Reports, corriamo tutta una serie di rapporti di prova una volta esportandoli in vari formati di esportazione, assicurarsi che l'output sia come desiderato, quindi continuare a eseguire regolarmente questi stessi rapporti, confrontando i risultati con i dati originali. Eventuali differenze poi si presentano come fallimenti di test.

Ha funzionato abbastanza bene per noi. Lo svantaggio di questo è che eventuali differenze minori che potrebbero non fare alcuna differenza vengono visualizzate come errori di test fino a quando i dati del test non vengono ripristinati.

Nota a margine: questo non è esattamente un test unitario ma piuttosto un test di accettazione. Ma non vedo come potresti veramente "testare" un intero report.

Answer 5

La mia idea attuale è quella di creare test a due livelli:

• Prove di unità: la struttura della relazione per consentire il test utilizzando alcune idee per testare un interfaccia utente, come Humble View. Il report stesso sarà reso il più stupido possibile. Dovrebbe consistere principalmente di semplici associazioni di campo. Gli elementi/oggetti di dati che fungono da origine di questi binding possono quindi essere sottoposti a test dell'unità.

• Test di accettazione: genera alcuni report di esempio. Verificale prima a mano. Quindi impostare un test automatico che esegue un confronto utilizzando diff.