Re: Basic DAO-"Service"-Test-Setup
Hi Kalle, > What is the mock used for (particularly in this case)? > You want to use the SessionSource to create a new Session if the > execution of your operation lasts longer than the lifetime of the > request is. If you are injecting a session, T5 manages the lifetime of > it and closes it at the end of the request handling. > Thank you very much for this piece of information, i have missed it in those tutorials I read. > That's one use case. The right approach for a given situation depends > on what specifically you are testing and what the circumstances are > for that particular use case. Similarly, the PageTester is hugely > beneficial for testing the logic within your pages, but there's no > benefit using it for testing your persistence queries. > That is the reason why I thought, I missuse the PageTester. Thanks for your help Regards Stefan -- View this message in context: http://tapestry.1045711.n5.nabble.com/Basic-DAO-Service-Test-Setup-tp5472574p5482482.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Basic DAO-"Service"-Test-Setup
On Mon, Feb 13, 2012 at 1:19 AM, stebac wrote: > What is the mock used for (particularly in this case)? > I commented out these two lines and it still worked, what is the purpose of > the SessionSource? Of course it "works" if you don't need the SessionSource (which is a T5 concept, not Hibernate). If your service takes a SessionSource as an injected parameter to obtain the Session, you have to pass a SessionSource to it for things to work. It should be fairly obvious from the sample code that the testing strategy (for those types of tests) is exercising the actual persistence logic, mocking up the Tapestry services as needed that are built on top of the specific persistence technology. You want to use the SessionSource to create a new Session if the execution of your operation lasts longer than the lifetime of the request is. If you are injecting a session, T5 manages the lifetime of it and closes it at the end of the request handling. > Just for beeing sure: > using your approach a can use the imlementation of the service, making > things more convinient. Here I use injection by contructor for the session. > So when T5 injects the current session, I can now hand it over in my > testcases. Is this the way it was meant originally? That's one use case. The right approach for a given situation depends on what specifically you are testing and what the circumstances are for that particular use case. Similarly, the PageTester is hugely beneficial for testing the logic within your pages, but there's no benefit using it for testing your persistence queries. Kalle - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Basic DAO-"Service"-Test-Setup
Hi Kalle, thank you very much for your quick response! I saw this approach before but did not understand it entirely. Maybe a shall supply a little bit more information about my situation: I have a typical t5-service consisting of an interface an the corresponding implementation. The Service is a DAO-Service for handling all DB-operations (like persistiing) transparently. The interface has some basic methods like: void add(Item) Item getItemById(Item) List getAll() My current Testsetuo is like following: I create the Service with a t5-PageTester instance and then i invoke several tasks to see if the service is working correctly. In my opinion this way of testing is not very efficient and error prone. For example when I add an Item to test the retrieval, hibernate operates on its cache so the retrieval is not tested correctly. This was the starting point for my question, as a kind of work around I wanted to clear the session every time a test tries to read something of the hibernate-session. This is not a very nice hack so I thought maybe there is a more elegant way of testing within t5 -> testing services (also with hibernate involved) seems to me as a rather basic task, but I did not really find a lot about this topic. So thanks again to you Kalle, to share your approach. When I tried to implement it I stumbled over some questions. What is the mock used for (particularly in this case)? I commented out these two lines and it still worked, what is the purpose of the SessionSource? Just for beeing sure: using your approach a can use the imlementation of the service, making things more convinient. Here I use injection by contructor for the session. So when T5 injects the current session, I can now hand it over in my testcases. Is this the way it was meant originally? Many thanks, regards Stefan -- View this message in context: http://tapestry.1045711.n5.nabble.com/Basic-DAO-Service-Test-Setup-tp5472574p5478557.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Basic DAO-"Service"-Test-Setup
The following is what I use. I use Mockito for mock-ups and basically
it's a real Hibernate session (and factory) with a mocked-up T5
HibernateSessionSource:
public abstract class PersistenceTest {
protected Session session;
protected Transaction transaction;
protected static SessionFactory sessionFactory;
protected HibernateSessionSource sessionSource;
@BeforeClass
public static void staticSetUp() {
AnnotationConfiguration configuration = new
AnnotationConfiguration();
configuration.addAnnotatedClass(...);
// add all...
sessionFactory = configuration.buildSessionFactory();
}
@Before
public void beforeTest() {
session = sessionFactory.openSession();
transaction = session.beginTransaction();
sessionSource = mock(HibernateSessionSource.class);
when(sessionSource.create()).thenReturn(session);
}
@After
public void afterTest() {
if (transaction != null) if (transaction.isActive())
transaction.rollback();
}
Kalle
On Fri, Feb 10, 2012 at 6:22 AM, stebac wrote:
> Hello there,
>
> I have a question about the usual way of testing with tapestry. I am using
> Tapestry 5.3.1 and TestNG. My latest tests are currently working, but it
> took me quite a long time to be at this point and still I think there will
> be a more intuitive and easier way to setup testing. This is my first
> contact with an IoC-Container so maybe its a very basic question:
>
> What I want to test: DAOs configured as tapestry-services using hibernate.
> My question: how can these services be tested easily?
> My Problem: The implementation of the DAO is using a hibernate Session to
> accomplish all tasks. During testing it might be nice to have access to this
> session.
> So is it possible to inject the same session in the test? Or inject a know
> session into the doa? Or is there no other way to let the session "leak" out
> of its service (for testing purpose )?
>
> The reason, why I want to have that session is:
> I had a Problem during my current setup using pagetester because of the
> session cache of hibernate, so my store and load methods did not always
> really operate on the database, so potential errors where not catched.
>
> I looking forward to hear your suggestions and opinions,
> with kind regards
> Stefan
>
> --
> View this message in context:
> http://tapestry.1045711.n5.nabble.com/Basic-DAO-Service-Test-Setup-tp5472574p5472574.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
