Configurazione asterisco di unità/integrazione

Question

I test di unità e integrazione vengono generalmente eseguiti come parte di un processo di sviluppo, ovviamente. Sto cercando modi per utilizzare questa metodologia configurazione di un sistema esistente, in questo caso il Asterisk soft pbx.

Nel caso di Asterisk, il file di configurazione è tanto un linguaggio di programmazione quanto qualsiasi altra cosa, completa di loop, salti, condizioni, ecc. E può diventare piuttosto complesso. Le modifiche alla configurazione spesso soffrono degli stessi problemi delle modifiche a un prodotto software complesso: può essere difficile prevedere tutti gli effetti senza test in atto. È peggiorato dal fatto che la natura del sistema è comunicare con entità esterne, cioè fare telefonate.

Ho alcune idee su come testare il sistema utilizzando file di chiamata (per creare chiamate specifiche tra estensioni) mentre guardo l'interfaccia del manager per eventi generati. Un test potrebbe quindi guardare per un risultato atteso, cioè la composizione *99# dovrebbe comportare la chiamata dell'applicazione di posta vocale.

I difetti sono ovvi: non teste il risultato effettivo, solo ciò che il sistema pensa è il risultato e probabilmente richiede una modifica del sistema in esame. È anche davvero difficile scrivere questi test sufficientemente da innescare solo sull'output previsto, specialmente se il sistema è in uso (cioè ci sono altre chiamate in corso).

È quello che voglio, un sistema di test per asterisco, impossibile? In caso contrario, hai qualche idea su come procedere in modo ragionevole? Sono disposto a dedicare un discreto tempo a sviluppo in questo e rilasciare il risultato con una licenza amichevole, ma non sono sicuro del modo migliore per affrontarlo.

Answer 1

Questa è ovviamente una vecchia domanda, quindi c'è una buona probabilità che quando le risposte originali siano state pubblicate qui quell'Asterisk non ha supportato i test dell'unità/ integrazione nella misura in cui lo fa oggi (sebbene l'API del framework di test unitarie sia andato il 12/22/ 09, così, almeno, esisteva).

Il framework di test unitari (e-mail di David dall'elenco Dev qui) consente di eseguire i test unitari direttamente all'interno di Asterisk. I test sono registrati con il framework e possono essere eseguiti / visualizzati tramite la CLI. Poiché tutto fa parte dell'asterisco, i test vengono compilati nell'eseguibile. È necessario configurare Asterisk con l'opzione --Enable-Dev-Mode e contrassegnare i test per la compilazione utilizzando lo strumento menuselect (alcune applicazioni, come App_VoiceMail, registrano automaticamente i test-ma sono la minoranza).

La scrittura dei test delle unità è abbastanza diretta - e mentre (ovviamente) non è completamente descritto come un framework di test unitari commerciali, fa il lavoro e può essere migliorato secondo necessità.

Questo molto probabilmente non è ciò che la maggior parte degli utenti di asterisk vorrà utilizzare, anche se gli sviluppatori di asterisco sono molto incoraggiati a verificarlo. Sia gli utenti che gli sviluppatori sono probabilmente interessati ai test di integrazione, che il ASTERISK TEST SUITE fornisce. Alla base, la suite di test è uno script Python che esegue altri script - che siano Lua, Python, ecc. La suite di test viene fornita con una serie di librerie Python e Lua che aiutano a orchestrare ed eseguire più istanze di asterisco. Gli scrittori di prova possono utilizzare applicazioni di terze parti come interfacce SIPP o asterisk (AMI, AGI) o una stessa combinazione per testare le istanze di asterisco ospitate.

Ci sono quasi 200 test ora nella suite di test, con più aggiunti su base abbastanza regolare. Potresti ovviamente scrivere i tuoi test che esercitano la configurazione dell'asterisco e farli gestire dalla suite di test - se sono abbastanza generici, potresti inviarli anche per l'inclusione nella suite di test.

Si noti che la suite di test può essere un po 'difficile da configurare: Leif ha scritto un buon post sul blog sulla configurazione della suite di test qui.

Answer 2

Bene, dipende da ciò che stai testando. Ci sono molti modi per gestire questo genere di cose. La mia preferenza è utilizzare i file di chiamate asterisk in bundle con il codice dialplan. Ad esempio: Crea un file di call per comporre un numero pubblico, una volta risposto, torna al contesto DialPlan specificato ed esegui tutta la mia logica di test (riproduci SoundFile, ascolta i chiavette, ecc.)

Ho scritto una libreria di file di chiamata asterisco che rende questo tipo di test estremamente facile. Ha anche molti documentazioni / esempi, dai un'occhiata qui: http://pycall.org/. Questo può aiutarti.

Buona fortuna!

Answer 3

È un enum in cui ogni istanza ha sovrascritto il metodo getResult.

Cosa dovresti tenere a mente è che un enum è più o meno solo una classe normale.

.

Come arriva quel filesizebench è un enum e non una classe?

Poiché viene dichiarato utilizzando la parola chiave enum invece di class.Un enum viene utilizzato perché SomeEnum ha un numero di istanze predefinite (conosci in compilazione).

Answer 4

Test unitari rispetto ai test di integrazione significa che il codice dovrebbe essere architetto, quindi la logica stessa è isolata da dipendenze esterne. Hai detto "Il file di configurazione è tanto un linguaggio di programmazione quanto qualsiasi altra cosa", ma questa è la cosa --- Lingue reali non hanno solo il flusso di controllo ma le capacità di astrazione, che ti consentono di scrivere la logica in un modo che può essere testato. Ecco perché tengo la logica al di fuori di Asterisk il più possibile.

Per i test di integrazione, script linphonec Per guidare la tua applicazione e associare la console Asterisk per vedere cosa sta facendo. È possibile utilizzare Docker e attivare istanze di asterisco temporanee per ogni test.