Strumenti di collaudo unità Tibco

Question

Qualcuno sa quali strumenti di verifica dell'unità sono disponibili quando si sviluppano i processi Tibco?

Nei prossimi mesi lavorerò su un progetto Tibco e sto cercando di individuare eventuali quadri di test delle unità esistenti che potrebbero rendere il lavoro più facile da costruire con un approccio TDD.

Finora, l'unico che sono riuscito a individuare si chiama BWUnit. Sembra ok ma è attualmente in beta e il suo software commerciale. Se possibile mi piacerebbe usare uno strumento open source ma fintanto che è in grado di fare un buon lavoro sarei felice.

Quindi qualcuno sa di altri strumenti di test dell'unità per lo sviluppo Tibco?

Inoltre, qualcuno ha esperienza con BWUnit? Quanto è utile/era?

Answer 1

Per i progetti BW, ho preparato il mio framework Unit Test basato sui processi BW. Quindi i test e le convalide automatizzati sono codificati nel progetto TIBCO stesso.

Per i progetti AMX, consiglio SOAPUI per il test automatico dei servizi. Tuttavia, ho codificato tutti i test unitari nella lingua sottostante, nel mio caso Java, usando JUnit. Le classi di implementazione sotto i componenti fanno riferimento l'una all'altra direttamente nei test di unità, ignorando il codice AMX che esegue la messaggistica.

Answer 2

C'è una vecchia struttura denominata Raccoon costruita sopra Tibco ActiveEnterprise.

Ha un componente per il test dell'unità denominato UiTest incentrato sulla messaggistica RendezVous.

Ultimamente, non sembra avere troppa attività.

Answer 3

Ho avuto un grande successo nella creazione di un livello di interfaccia soap per ciascuno dei miei processi (prendendo gli stessi argomenti) e sfruttando lo SoapUI per eseguire tutti i test guidati da alcune tabelle di database.

Edit:

Quello che ho descritto è più o meno come BWUnit sta funzionando: (. Forse con un po 'meno lavoro manuale, ma lo stesso concetto) crea un'interfaccia di servizio Web intorno a ciascuno dei vostri processi

test di ingresso (SoapUI) -> testabile Interface (sapone/EMS/etc) -> processo esistente -> Esci Interfaccia -> le asserzioni (SoapUI)

Si potrebbe fare il test all'interno di TIBCO per sé, con i file, RV, JMS, o qualsiasi input per quel matt er, eccetto che stai scrivendo tu stesso tutto il codice di asserzione test piuttosto che usare uno strumento esistente che ha tutto incorporato. Puoi quindi affidarti a SoapUI per generare tutti i tuoi rapporti JUnit ecc.

Se vuoi davvero È possibile aggiungere un obiettivo soapui al proprio script di costruzione per includere i test unitari e/oi test funzionali per ogni build una volta implementato.

Answer 4

Preliminare sul protocollo utilizzato (cosa viene utilizzato). Racoon e SoapUI sono stati menzionati. Con loro puoi testare su un livello "per modulo". Questo è il test dei componenti o del sistema. Particolarmente utile per i test delle prestazioni. Tuttavia questo è il modo più comune per testare i componenti di tibco.

Daremo un'occhiata a BWUnit, sembra interessante e integrato con i server CI (ho costruito uno strumento simile in un progetto). Un difetto di questo approccio potrebbe essere che i sistemi TIBCO di solito sono composti da diversi strumenti e non solo BW, questo significa che per il sistema totale vengono utilizzati componenti Java, server C++ e così tanto.

V'è anche uno strumento commerciale denominata GHTester (http://www.greenhatconsulting.com/ghtester/)

Se si utilizza RV si potrebbe avere uno sguardo a http://www.rvsnoop.org/ per catturare i messaggi in un formato replayable gratuitamente (strumento OSS che ho iniziato)

Answer 5

Con BW-TEST si possono praticare TDD e aggiungere i vostri progetti per il vostro CI Check it out sul http://nicosommi.com/?p=209

E 'open source

Answer 6

Cercando di fare una metodologia simile TDD con sapone interfaccia utente non sarebbe molto efficace. Ho usato This for BW e non ottieni lo stesso livello di granularità e comfort da una suite di test di unità completa. BWUnit è un buon strumento e se hai un buon rapporto con i tuoi ragazzi di TIbco PSG potresti essere in grado di ottenere TibUnit che è un PSG Ware come CLE.

Abbiamo anche elaborato un piano per utilizzare un framework di test Unit esterno come .net e quindi utilizzare un pattern controller per scambiare i processi utilizzando il flag di override del processo dinamico. Così esentaially avremmo un canale di controllo che avrebbe detto qualcosa come

controllo - Processo 1 Override -/Processi/SomeProcess.process - Processo 2 Override {} vuoto

così nel vostro unit test nel tuo setup potrai chiamare BW usando il tuo canale di controllo (EMS o HTTP) e dirgli di caricare un processo diverso. Mentre questo funziona è ancora un hack a causa della funzionalità limitata di Designer.

Abbiamo anche esaminato Service Grid e BWSE e questo non sembra darci altro. In realtà un po 'più limitante.

Answer 7

IBM RIT è uno strumento molto valido per lavorare su questo tipo di scenari, può aiutarti a far valere diversi scenari e anche a valutare la copertura del codice.

Answer 8

Raccomando IBM RIT. fa parte dello stack IBM RTW. Potete usarlo facilmente nei modelli di consegna TDD e CI/CD.