Asynchronous testing with TestNG

[Cedric Beust]

Dan and I exchanged a few emails on this topic recently, I thought I would
extend the CC's.

Read on (start at the bottom...).

--
Cédric



> -----Original Message-----
> From: Dan Bush [mailto:dan....@gmail.com]
> Sent: Tuesday, August 30, 2005 10:30 AM
> To: Cedric Beust
> Subject: Re: TestNG
>
> That does address an async situation by neatly handling the
> timeout and providing the callback hook. However it doesn't
> offer much in the way of an enterprise level solution as far
> as the framework goes. At the end of the day you would still
> have to manage a socket and the message consumption/dispatch
> functionality. All that boiler plate code detracts from the
> simplicity of TestNG and would add unnecessary overhead to
> actually implementing the test. The shear fact that threading
> code would have to be introduced into the test is a lot to
> ask in addition to implementing the test. It would be much
> more elegant if the framework provided all that functionality
> for you...
>
> What about introducing proxy functionality to the framework
> which could intercept callbacks and dispatch them to the
> appropriate async test?
>
> This is a quick pseudo example to help demonstrate the idea:
>
> class AlertTest {
>
> private String _alertId;
>
> @Selecter(name = myAlert)
> public Selecter getSelecter() {
> // this allows the proxy component to identify and dispatch the
> // inbound http requests to the appropriate test(s) ...
> Selecter s = new Selecter {
> public boolean select(HttpRequest reg) {
> return req.getParameter("alert.id").equals(_alertId);
> }
> };
> return s;
> }
>
> @Test(groups = { "send" })
> public void sendAlert() {
>
> // creat the alert
> Alert a = new Alert("MyAlert");
> Calendar c = Calendar.getInstance().add(Calendar.SECOND, 10);
> a.setTriggerDate(c.getTime());
>
> // schedule it
> QSAlertServiceServiceLocator locator = new
> QSAlertServiceServiceLocator();
> QSAlertService service = locator.getQSAlertService();
> _alertId = service.schedule("MyAlert",
> "http://localhost:7001/testng/callback");
> }
>
> @Test(timeOut = 20000, selecter = myAlert)
> public void callback(HttpRequest req, HttpResponse resp) {
> // retrieve the alert; could be a SOAP message or simply package
> // in the request as a parameter
> assert(req.getParameter("alert") != null);
> }
>
> ...
>
> You could even go as far as to abstract the whole proxy
> feature so the framework could handle JMS and what ever else
> in addition to HTTP messaging transparently.
>
> What do you think?
>
>
>
> On 8/29/05, Cedric Beust <cbe...@google.com> wrote:
> >
> >
> > Hi Dan,
> >
> > Please take a look at this:
> > http://www.beust.com/weblog/archives/000236.html
> >
> > and let me know if it answers your question...
> >
> > --
> > Cedric
> >
> >
> >
> > From: Dan Bush [mailto:dan....@gmail.com]
> >
> > Have you put any thought around embedding support for async
> testing in
> > reguards to the future of the TestNG framework?
> >
> > For example you want to use TestNG to test a shiny new
> alerting service ...
> >
> > Currently, I am planning on integrating jetty and having my
> tests do
> > some kind of registration process in combination with a correlation
> > component so call backs can be be consumed, identified and then
> > dispatched to the originating test for completion. I need
> some king of
> > proxy solution like Cactus but geared for TestNG and with
> async capabilities.
> >
> > Dan Bush
> > Architect
> > Corporation Service Company
> > db...@cscinfo.com
> > dan....@gmail.com
> > (800) 927-9801 x3254
> >
>