I've written a JEE6 application using CDI and JPA. My tests are written in JUnit. I'd like to run the database tests against an in-memory HSQLDB database in order to make sure my JPQL (which I consider 'code') is tested. My motivation is that that changing a JPQL statement with a mocked out EntityManager would lead to successful test execution of the code unit.
I'm using Guice and Jukito to run other (non-jpa) tests.
Does anyone have an example for this? I've tried looking around and I've yet to find a good example or framework project to handle this.
Arquillian persistence? DBUnit?
I'm new to JPA so after searching for a while and trying I could not figure how to do the following thing.
I want to use JPA annotated classes in unit tests, production - resin app server, and in development mode for GWT (jetty).
The problem is that I could use Persistence.createEntityManagerFactory together with META-INF/persistence.xml in unit tests and it works fine. However, it does not work on resin and I get the same error in GWT development mode.
I could get it working on resin by using #Inject annotation and resin-web.xml but not sure how to use it in GWT dev mode.
I'd like to use the same code if possible for all 3 cases: unit tests, Jetty for GWT, and resin in production. I also like to let resin handle connection pooling, and avoid using Spring if possible.
Are the any tutorials that cover this particular case or any code samples? What are the best practices?
Since you're open to using Guice, Guice can piggyback off the existing #Inject annotation.
So, the idea here is to do the same thing that Resin does when it runs your code. Resin recognizes the #Inject annotation, finds the appropriate class and instantiates, than injects that value. We can get Guice to do the same thing for us for your unit test and GWT modes.
The biggest change is you'll have to make a seperate profile for your persistence.xml. Copy your existing file and change the name. For instance, if your existing PU is "myJPAUnit", in the new file, name it "myJPAUnitLocal" like this:
<persistence-unit name="myJPAUnitLocal" transaction-type="RESOURCE_LOCAL">
</persistence-unit>
The other key change is to change transaction-type to RESOURCE_LOCAL as in the above example because your transactions aren't managed by a container.
I won't cover the pre-reqs, because there are a lot of good tutorials on Google about running Junit tests and webapps with Guice, but I thought that might be a tripping point for you. The remaining steps are something like: add the Guice filter, extend the GuiceServletContextListener, add the JPA injector to that, add your listener to the web.xml.
How to initialize Guice in a webapp: http://code.google.com/p/google-guice/wiki/ServletModule
How to add a JPA injector to Guice: http://code.google.com/p/google-guice/wiki/JPA
Good luck!
I used to use DBUnit to populate my database with classes/records expected by my Unit tests, and I noticed that they do sort of the same thing using Boostrap.groovy in Grails, but I am wondering if this is the kosher way of doing this in Grails.
Is it better just to setup DBUnit within Grails? Or does Grails have it's own way of doing this?
I wouldn't recommend Bootstrap.groovy for loading test data. It's likely to become unwieldy, particularly if you want to use different datasets for different tests. There are a number of DBUnit Grails plugins that you could use to simplify integrating DBUnit into a Grails app (though you can also just use the JAR directly).
There are also some plugins that provide Grails-specific ways of loading test data. The Fixtures plugin seems to be one of the most popular.
I've always used a combination of Bootstrap.groovy using the environments block and the tests setUp()/tearDown() methods. Sometimes utilizing a base test class.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
This may be a naive question, but I am new to both the junit and hibernate frameworks and I was wondering what the best way to go about unit testing an application that is largely calls to hibernate, or if it is even necessary to do so?
What is the best practice here?
EDIT:
Spring seems to be the big suggestion here. Unfortunately this may be alittle too much to bite off for one project. Junit, Hibernate and Spring are all new to me, and while they are all technologies I want to get under my belt, I think trying to incorporate them all into one project may be too overwhelming for me.
Links to tutorials and/or book suggestions are welcome.
Keep in mind the difference between unit testing and integration testing.
Unit tests should be testing code without any outside dependencies. These dependencies are mocked using a framework like, for example, JMock.
Integration tests are important too but the major drawback of them is that they take a long time to run. You can run thousands of true unit tests in a couple of seconds, but it's not the same with integration tests.
Depending on the size of your project/development team you might want to prioritize true unit tests over integration tests. Both style of tests are important but if you are pressed for resources, just going with Unit testing may be a better idea.
I wrote an application by myself that unit tested the Web (with Spring MVC this is easy) and Service layers, as well as domain objects. But I left the DAO alone because I didn't want to write a bunch of slow integration tests. If I had more people on staff I would have gone with integration tests as well, but in this case I didn't feel the time spent would be worth it.
As for best practices:
use an embedded database for running your tests if possible, so that you don't need a full deployed relational database just to run your tests (locally, or on your continuous build server if you have one). That way you also don't need to (necessarily) worry about rolling back etc, you can just recreate the database when you need to. Testing with an embedded database doesnt test peculiarities that could come up when you use your specific production database, but it does test your code, which should suffice.
You can also use DbUnit, an extension to JUnit, to easily fill the database with expected rows and put it in a known state, before you run your Hibernate tests.
Best practice? I use Spring and make all my tests transactional. I perform the test and rollback all the changes so I don't change the state of the database.
I like to use a in memory hsqldb for testing. The process for each hibernate POJO is:
Create the object
Persist it to the DB
Clear the session
Get it from the DB
Assert the objects are equal.
For DAOs, I create and persist enough objects to accurately test the methods, then run the tests and delete the objects as necessary to not intefere with other tests.
Hibernate source includes a lot of unit tests, I would recommend going through those and adapting a similar approach.
You can also look at the CaveatEmptor which the sample application developed for the book "Java Persistence with Hibernate"
If you're using Hibernate for Domain rich models, Unit testing domain logic is as simple as testing a POJO and Hibernate doesn't get in your way. The only caveat here is, For bidirectional mappings, you might have to set the object on both sides for unit tests.
Integration testing with database is generally not done for simple mappings. However it is suggested in the case of exquisite mappings like Single table inheritance etc. The only thing to remember here is, you may have to explicitly flush to database sometimes.
Sure, you'd unit test your persistence tier if it wasn't written in Hibernate, wouldn't you?
Create a given persistence interface that's implemented using Hibernate, instantiate some sample objects, perform CRUD operations, and ask JUnit to assert that the operations were successful. Same as any other class.
You could use Spring to help here.
It has a great unit test framework, you can use it to test CRUD ops and then rollback changes - great if you don't have the capability to reload a database every time.
Write a simple layer that passes requests to Hibernate. Then use a mocking library like EasyMock or JMock to assert that your Hibernate-veneer layer is correctly called by your application classes. This is nicely described in the partially-complete JMock book (scroll down to the test smell "everything is mocked").
Two cases are easy to test:
When practical, perform your various calculations and transformations in functions that don't know about saving or loading entities. If you can make these pure functions, so much better.
For functions that only save to the database without reading from it, you can choose not to save when testing.
The simplest (crudest) way to do #2 is by adding a reallyUpdate parameter to the function, then surrounding each "save" call with:
if (reallyUpdate) {
HibernateUtil.saveOrUpdate(theThing);
}
For me these were the lowest hanging fruit.
im using Struts 1.2.x and Ibatis 2.x version for development, so i finish yesterday and now i want to perform test this is my first time trying to work with JUnit, I already make test but in JavaApp not running on server, so how can I simulate or generate mocks with server behavior, and wich mocks are recommended for Struts and Ibatis built-in Environment?
for example how can i set accerts for login screen?
I know about StrutsTestCase im using it, and about Cactus are for containers and mocking for non containers scenaries, i want to view a demo using struts and ibatis cause I dont know how to retrieve data from mapping. Thanks
sorry about my English
Thanks in advance!
Have you looked at HttpUnit? I tried it for Servlet testing, completely different from Struts Actions and such - I know, but it had some decent tutorials.
You also might want to look at StrutsTestCase for JUnit. That project should be a sufficient start for unit testing struts. It also mentions Cactus, which is a framework for testing web applications on the server side.
Actually it all depends on how far you want to go with testing. You probably should have started with writing a test first, Test Driven Design you know ;) It just works. Not that I do it all the time...