Application tests with GuiceBerry,Jetty, GWT and Selenium

35 views
Skip to first unread message

Miroslav Genov

unread,
May 22, 2009, 2:52:33 PM5/22/09
to guiceber...@googlegroups.com
Hello,
I'm trying to use GuiceBerry for testing of one sample GWT form that I
made to make some kind of prototype. Everything was fine until the
moment when I had to use re-mapper to inject fake objects instead of
real objects. I think that the problem is mostly because
the server is ran as different process and GuiceBerry doesn't have an
access to Server's Guice injector to create the remap. To make the
things more clear what I'm doing I'm applying my sample application with
the whole code. The entry point of my sample application
test is at test/com/jadm/invoice/client/functional/SampleTest. In this
test case server is not started by GuiceBerry's test listener, because
this is a prototype on which I just wanna make the things to work.

Hope that anyone can help me on this.

Thanks in advance

Regards,
Miroslav

invoice-app-with-guiceberry.rar

Miroslav Genov

unread,
May 22, 2009, 4:41:19 PM5/22/09
to guiceberry-users
I think that now I got the idea how to solve my problem. It seems that
I have to use controllable injection in this case. The last minutes of
the presentation are crucial and I advice all guys that are interested
on this they must look last minutes carefully. Now let's get back to
the point.

Here are the thoughts that came into my head when I saw the last part
of the presentation. Please let me know if I'm wrong or totally wrong.

Lets say that we have a simple application with login form that
contains two fields: username and password. To may user be log-in into
the system the application have to ask the database where the entered
username and password are matching. (Probably this is not a heavy
scenario, but it's simple). Here comes part where I want to inject a
Fake login controller that will use some a Hashtable to store
information
about few users which I will use for testing. And here is the deal,
the server has to use FakeController on some tests and RealController
on other tests. As I understood this is realized with cookies.
The test case has to send and http request with some cookie value
which probably is holding the Testing Identifier which identifies the
test to may server handle multiple simultaneous tests. After server
receives such request it has to replace the injector class with Fake
implementation and server probably have to do this with any GuiceBerry
classes.After the implementation is changed then test is ran with
configuration that he is using. I saw that GuiceBerry has dependency
to servlet-api-2.4 which means that there is a such servlet that is
doing this job. Hope that anyone can point me to it.

If my assumptions are right then probably this is a simple structure
that I have to use in my project:
invoice-app-with-guiceberry
src/
com.jadm.invoice.client
com.jadm.invoice.server.dao.jdbc
com.jadm.invoice.server.dao.fake --> this should be placed to may
server inject any of the fake classes when new controller injection
request is received
com.jadm.invoice.server.service.fake -> same as fake dao
com.jadm.invoice.server.service.impl
com.jadm.invoice.server.environment
com.jadm.invoice.server.
test/
com.jadm.invoice.client.integrationtests
com.jadm.invoice.client.applicationtests
com.jadm.invoice.server.dao.jdbc (unit and integration tests)
com.jadm.invoice.server.service (unit tests)
war/
index.jsp
index.css


With this structure, when the server code is deployed the server will
have runtime dependency to fake and to the real implementation and may
change any of them.


Regards,
Miroslav
>  invoice-app-with-guiceberry.rar
> 4103KViewDownload

Luiz-Otavio Zorzella

unread,
May 27, 2009, 3:46:15 PM5/27/09
to guiceber...@googlegroups.com
Miroslav,

many sorries for the delay in replying. I was out of the country and
then on training for the past 2 weeks.

The most feature-complete and elegant way of having the test bypass
some server-side function (say, calling the real auth server on login)
is, indeed, controllable injections. There are 4 reasons why the
documentation is still lacking here:

* it's such an advanced feature

* it will take quite a lot of effort to properly document it

* it's current impl (though functional) is still a little
not-as-polished as I want it to be, and it will take me some effort to
polish it up

* most importantly it's built on some Guice APIs that are in flux for
Guice 2.0. I was hoping to wait for Guice 2.0 release before I messed
with that, my apologies... Let me talk to Jesse about the release, and
see what I can do for you.

Meanwhile, in honor of your needs, I'll spend some time documenting
the issue properly, and what's already here. I'll send you a few
drafts.

Z

Luiz-Otavio Zorzella

unread,
May 27, 2009, 3:49:24 PM5/27/09
to guiceber...@googlegroups.com
Correction: Guice 2.0 was just released while I was on my trips! I'll
get to work right away!

Z

Miroslav Genov

unread,
May 27, 2009, 6:50:29 PM5/27/09
to guiceber...@googlegroups.com
Thanks a lot. It would be really nice if you have some time to do any of
the following things.

Regards,
Miroslav
Reply all
Reply to author
Forward
0 new messages