Come eseguire il test dell'unità in Microsoft Dynamics AX 2012 in un progetto del mondo reale

Question

Dynamics AX 2012 viene fornito con il supporto per il test dell'unità.

Per test significativi, è necessario fornire alcuni dati di test (memorizzati nelle tabelle del database).

Per ottenere un risultato riproducibile dei test di unità, è necessario che gli stessi dati vengano memorizzati nelle tabelle ogni volta che vengono eseguiti i test. Ora la domanda è: come possiamo realizzare questo?

Ho appreso che esiste la possibilità di impostare il livello di isolamento per TestSuite su SysTestSuiteCompanyIsolateClass. Ciò creerà una società vuota ed eliminerà la società dopo che i test sono stati eseguiti. Nel metodo setup() posso riempire i miei testdata nelle tabelle con istruzioni di inserimento. Questo funziona bene per piccoli scenari ma diventa ingombrante molto velocemente se si dispone di un progetto di vita reale.

Mi chiedevo se c'è qualcuno là fuori con una soluzione pratica su come utilizzare X ++ Unit Test Framework in uno scenario reale. Qualsiasi input è molto apprezzato.

Answer 1

Bene, dal mio punto di vista, non sarete in grado di sfruttare più di quello che avete indicato dal framework standard. Quello che puoi fare è più vicino alla gestione delle versioni. È possibile impostare un ambiente di integrazione con i dati mirati e inserire il modello di nightbuild in questo environmnet alla fine del processo di generazione e quindi eseguire i test. Sì, sarà necessario più sforzo per configurarlo e per mantenere, ma è l'unica soluzione che ho visto fino ad ora per disporre di un insieme ampio e coerente di dati per l'esecuzione di test di unità o integrazione.

Answer 2

Concordo sul fatto che la creazione di dati di test in un'azienda nuova e vuota funziona solo per scenari o scenari abbastanza banali in cui è stata implementata l'intera struttura dati. Ma non appena sono necessarie strutture dati esistenti, questo approccio può richiedere molto tempo.

Un approccio che ha funzionato bene per me in passato consiste nell'eseguire i test unitari in un'azienda esistente che ha già la maggior parte dei dati di configurazione (ad esempio configurazione finanziaria, impostazione dell'inventario, ...) necessaria per eseguire il test. Il test stesso viene eseguito in un blocco ttsBegin - ttsAbort in modo che il test dell'unità non crei effettivamente alcun dato.

Un altro approccio consiste nell'implementare metodi di fornitore di dati indipendenti dal test, ma creare dati che vengono spesso utilizzati nei test di unità (ad esempio, un metodo che crea un prodotto). Ci vuole del tempo per creare un insieme utile di metodi di data provider, ma una volta che esistono, scrivere test di unità diventa molto più veloce. Vedere SysTest part V.: Test execution (results, runners and listeners) su come Microsoft utilizza un approccio simile (o almeno ha usato per il 2007 per AX 4.0).

Entrambi gli approcci possono anche essere combinati, è possibile chiamare i metodi del fornitore di dati all'interno del blocco ttsBegin - ttsAbort per creare i dati necessari solo per il test dell'unità.

Un altro metodo utile è utilizzare doInsert o doUpdate per creare i dati di test, soprattutto se si è interessati solo a pochi campi e non è necessario creare un record completamente valido.

Answer 3

Penso che il quadro di test unitario sia stato un ripensamento. Per poterlo utilizzare veramente, Microsoft avrebbe dovuto fornire classi di test unitari, quindi quando si personalizza il codice, si personalizzano anche i test delle unità.

Quindi senza di esso, in pratica, i test dell'unità di codifica sono rimasti invariati che tentano di includere il codice base insieme alle modifiche, il che è un compito enorme.

Dove penso che si possa effettivamente utilizzare si tratta di personalizzazioni isolate che svolgono alcune funzioni, e non sono pesantemente costruite sul codice di base. E anche con personalizzazioni che sono integrazioni con sistemi esterni.

Answer 4

Per test significativi occorre fornire alcuni dati di test (memorizzati in tabelle nel database).

Come già indicato da qualcun altro, ho trovato il modo migliore di sfruttare un'azienda esistente per i dati. Nel mio caso, diverse società esistenti.

Per ottenere un risultato riproducibile degli unit test abbiamo bisogno di avere i stessi dati memorizzati nelle tabelle ogni volta che i test vengono eseguiti. Ora la domanda è, come possiamo realizzare questo?

Abbiamo creato helper di test, che ci aiutano a "eseguire il test", automatizzando ciò che una persona farebbe - darvi architettato la vostra applicazione per essere testabile. In sostanza, la nostra classe di test utilizza gli helper per eseguire il test, quindi fornisce la maggior parte del valore nella convalida dei dati creati.

ho imparato che c'è la possibilità di impostare il livello di isolamento per il TestSuite a SysTestSuiteCompanyIsolateClass. Ciò creerà una società vuota ed eliminerà la società dopo che i test sono stati eseguiti. Nel metodo setup() posso inserire i miei testdata nelle tabelle con le istruzioni di inserimento . Funziona bene per piccoli scenari ma diventa ingombrante molto velocemente se si dispone di un progetto di vita reale.

Non ho trovato questo pratico nella nostra situazione, quindi non l'abbiamo sfruttato.

Mi chiedevo se c'è qualcuno là fuori con una soluzione pratica di come utilizzare l'++ Unità quadro di prova X in uno scenario del mondo reale. Qualsiasi input è molto apprezzato.

Abbiamo utilizzato il framework di test come indicato sopra e ha funzionato per noi. la chiave è trovare gli scenari corretti da testare, fornisce anche una buona base per scrivere classi testabili.