I have written my own hibernate dialect for a RDBMS. What is the best way to test the dialect? Are there any testsuites/tests that could be helpful for me? What is the best way to make sure, that my implementation is correct/supports all necessary features?
This is purely from reading stuff from the Hibernate GitHub repos, not from experience with "doing" Hibernate testing. However, it may be sufficient to get you started ...
The Hibernate matrix testing framework allows you to run tests against specific database backends; see https://github.com/hibernate/hibernate-matrix-testing. The README.md file says how to configure the framework for a specific database.
The Hibernate ORM tree includes a number of tests for the core of Hibernate; see https://github.com/hibernate/hibernate-orm. The README.md for that project mentions Gradle tasks for running the tests. (I haven't looked at the available tests in detail, but since the ORM tree includes the "dialect" classes for a range of database, I would imagine that includes the corresponding tests.)
Hibernate's build and test framework is implemented using Gradle, so I expect that you will need to get your head around that technology to figure out how it all works.
Not aware of any such suite or tests. To start with:
test various query scenarios & see if queries generated are running fine for that DB - when ran standalone.
test exceptions expected in all scenarios.
check on how it behaves for a new/old version of the DB driver.
Best of luck!
Related
I am using Play 2.4 with the Flyway-Play module.
Is there are way to clean and recreate the database between tests using this plugin? Some of my unit test have database effects which are not trivial to reverse, and it would be nice to be able to start afresh after these tests.
The documentation for the flyway-play module states:
In Test mode, migration is done automatically.
However, this seems be only once before running all tests. It would be nice to have programmatic control when preparing and cleaning up tests.
Not sure how flyway is integrated in the play framework (no experience with that), but it looks like what you are looking for is the flyway cleancommand.
Drops all objects in the configured schemas.
Flyway documentation: clean
I'm looking for a simple way to test Hibernate HQL criteria queries. I've tried using IntelliJ's Hibernate Console support, but I've run into problems.
Is there a standalone tool that provides a simple way to test HQL queries? A simple console program that creates the session factory and executes a query passed as an argument would suffice.
You can use the H2 (JDBC in-memory) database, and jetty for your container, to create a container and context that will execute hibernate queries in the unit-test phase of your build (or from JUnit).
Using a console would be my first choice for just playing with HQL (eg Hibernate Tools for eclipse). But if that doesn't work, I would just use JUnit. My team uses that strategy to test the HQL queries that we use in production code, and occasionally to help write queries in the first place.
The test setup involves setting up an in-memory database (we use HSQLDB, but there's others). Insert data either with Hibernate or with raw SQL. Then configure a Hibernate SessionFactory to connect to it, and run your HQL.
We also use this to test other kinds of Hibernate settings or behaviors, and has the side benefit of being a full test suite on Hibernate for our purposes so that we can upgrade and have confidence that nothing we need has changed in an unexpected way.
I doubt it's possible to have such a tool as a separate app, you'll need to specify a hibernate configuration (which might be in Spring Context), and it should be able to find the classes and their HBM files. Moreover you might use different UserTypes or anything like that from other JARs, so I wouldn't even search for it.
For me the best tool is a unit testing framework + debugging facilities of your IDE - you can just stop at some point where you have a session created and do whatever you want in this mode. In IntelliJ for instance, aside of usual expressions, you can put code fragments during debugging which might help you with Criteria API.
Last time I had to do this kind of work I used DbUnit to test my data access layer in which I was using JPA 2.0 with Hibernate
You could try a JUnit approch.
At work we are trying to simplify an application that was coded with an overkill use of Spring Remoting. This is how it works today:
(Controllers) Spring MVC -> Spring Remoting -> Hibernate
Everything is deployed in a single machine, Spring Remoting is not needed (never will be needed) and adds complexity to code maintenance. We want it out.
How to ensure everything works after our changes? Today we have 0% code coverage! We thought on creating integration tests to our controllers so when we remove Spring Remoting they should behave exactly the same. We thought on using a mix of Spring Test framework in conjunction with DBUnit to bring up Oracle up to a known state every test cycle.
Has anyone tried a similar solution? What are the drawbacks? Would you suggest any better alternative?
It always depends on the ratio effort / benefit that you are willing to take. You can get an almost 100% code coverage if you are really diligent and thorough. But that might be overkill too, especially when it comes to maintaining those tests. But your idea is good. I've done this a couple of times before with medium applications. This is what you should do:
Be sure that you have a well known test data set in the database at the beginning of every test in the test suite (you mentioned that yourself)
Since you're using Hibernate, you might also try using HSQLDB as a substitute for Oracle. That way, your tests will run a lot faster.
Create lots of independent little test cases covering most of your most valued functionality. You can always allow yourself to have some minor bugs in some remote and unimportant corners of the application.
Make sure those test cases all run before the refactoring.
Make sure you have a reference system that will not be touched by the refactoring, in order to be able to add new test cases, in case you think of something only later
Start refactoring, and while refactoring run all relevant tests that could be broken by the current refactoring step. Run the complete test suite once a night using tools such as jenkins.
That should work. If your application is a web application, then I can only recommend selenium. It has a nice jenkins integration and you can create hundreds of test cases by just clicking through your application in the browser (those clicks are recorded and a Java/Groovy/other language test script is generated).
In our Spring MVC / Hibernate (using v3.4) web app we use an Oracle database for integration testing.
To ensure that our database is in a known state each time the test suites are run, we set the following property in our test suite's persistence.xml:
<property name="hibernate.hbm2ddl.auto" value="create"/>
This ensures that the db schema is created each time our tests are run based on the Hibernate annotations in our classes. To populate our database with a know data set, we added a file named import.sql to our classpath with the appropriate SQL inserts. If you have the above property set, Hibernate will run the statements in import.sql on your database after creating the schema.
I want to create a test suit for my java web application. Its a JSP applications with JDBC connectivity . My requirements are as follows,
1 - I should be able to test my database logic (Queries etc) through my models.
2 - Its great if i could test my .jsp pages as well (if possible)
After doing some research I found that DBUnit is good for database backend system testing, but unfortunately i couldnt find any good resource as a starter
What are you all think about testing options I have and it would be great if you could post some links to resources/ examples as well
EDIT:
and I have come across with mock objects (like JMock..), wonder I could use it as a replacement for DBUnit ?
thanks in advance
cheers
sameera
It's not clear from your question if you want to run Integration tests (Front end + back end) or Unit Tests against you Database layer.
If you need a tool that allows you to write Integration tests, you should definitively look at Selenium.
With Selenium you can generate functional tests by simply navigating your web site (JSP pages) and asserting that stuff on the page exists or it's equal to some values.
Selenium comes with a Firefox plugin that will basically generate the code for you. You can replay the test in the browser or export them as Java code and make them part of your test suite. Selenium is an invaluable tool.
The drawback of using a tool like Selenium is that your application need to be deployed somewhere before you can run your test suite. This may be a limitation if you plan to run automated tests generated using Selenium.
If you are only interested in testing your database access code (DAO, Data Access Layer) DBUnit is the perfect tool.
Generally, DBUnit is used to initialize the database tables before testing and, less often, to run assertions on the database content. DBUnit uses an XML based format to represent the data that will be inserted into the database.
The XML files containing the data to pre-populate the db are normally triggered by a build script (Ant, Maven, etc.) or directly in your unit test code.
I have used both approaches, it really depends on how your code is structured and how you access the database (Hibernate, Spring+Hibernate, JDBC...).
If your database is not too big, I'd recommend you populate it just before running your test suite. Alternatively, you can populate only the tables that you are interested in testing prior to every test.
Here is a link to Unitils, that is an additional library that can be used on top of DBUnit to simplify the database testing strategy. I think it can be used as a reference to get you started:
http://www.unitils.org/tutorial.html#Database_testing
Here is anoter link (quite old, 2004) showing the basic mechanics of DBUnit:
http://onjava.com/pub/a/onjava/2004/01/21/dbunit.html
DBUnit's official getting-started article here worked for me. Re: database logic testing, you might also want to check this out.
As for JSP testing, I have used Cactus to test my servlets before with success. However, I'm don't know about its JSP-testing facilities.
For your 1st question have a look at this StackOverFlow thread...
For 2nd, I would go with Chry's suggestion of Cactus or Selenium.
Hope that helps.
My integration tests would run much faster if I used in-memory-database instead of PostgreSQL. I use JPA (Hibernate) and I need an in-memory-database that would be easy to switch to using JPA, easy to setup, and reliable. It needs to support JPA and Hibernate (or vice verse if you will) rather extensively since I have no desire to adopt my data access code for tests.
What database is the best choice given requirements above?
For integration testing, I now use H2 (from the original author of HSQLDB) that I prefer over HSQLDB. It is faster (and I want my tests to be as fast as possible), it has some nice features like the compatibility mode, the dev team is very responsive (while HSQLDB remained dormant for years until very recently).
I've been using HSQLDB in-memory for integration testing JPA/Hibernate persistence in Java. Starts pretty quickly, doesn't require any special setup.
The only issue I've seen so far with using HSQLDB with Hibernate was to do with batch size needing to be set to 0, but that might just have been related to an old version. I'll have a dig and see if I can find details of that problem.
Derby supports an in-memory mode these days, it is no longer marked experimental.
I use Derby. For one thing it is about 3 less lines of code per unit test since there is no need for a shutdown after the test. However, you need to use a JPA implementation that can drop and create tables such as EclipseLink.
Derby can also initialize a new in-memory database from a file so you can have a reference database and revert to it at anytime.
For unit testing though, I prefer to create my objects in my unit test's #Before logic I find it easier especially with JPA as it allows me the flexibility to do refactorings and not have to worry about the underlying database structure, other tools such as DBunit rely on practically a static structure and refactoring implies changing of the DBunit XMLs manually rather than relying on Eclipse's refactoring capabilities.