How should I be adding this functionality into my test framework? Should I be using Hibernate or standard JDBC? I need to run a stored procedure which exists in one of my databases, pass in 4 parameters and then grab the results to assert against.

I need to verify using the database as I cannot verify it on mobile devices themselves due to the nature of my work they are completely secure/bespoke android OS so using the likes of appium is not a possibility.

Could you post an example of using Hibernate to execute a paramaterised SP and grab the result set including dependencies/configuration necessary in doing so?


  • I wish I had time to offer a good answer, but I would offer some advice: the closer your test is to the real code, the better. So if your production code is using hibernate to execute a stored procedure, try doing that in your test too. – corsiKa Mar 12 '17 at 20:16
  • no problem at all, thanks. I just want to see the results of the stored procedure as I am unable to verify programmatically on the android device(s) if a particular thing is visible when logged in on that device. so if the SP which is executed to display the users modules returns me the result I am happy to pass my tests based on this and keep a manual test to assert that via the GUI also. – symon Mar 12 '17 at 20:22
  • If your question is how to write the code to run a stored proc and read the results, that's really a question for StackOverflow . . . – ernie Mar 13 '17 at 2:02
  • 1
    There's kinda 2 questions. 1) What's an appropriate way to test stored procedures, and 2) give me an example of invoking an SP using Hibernate. I think (1) belongs here and (2) belongs on SO. I'd suggest @symon search SO for (2) and if nothing can be found, ask the question, and edit this question if (1) is also important. – Mark Lapierre Mar 13 '17 at 6:28

If you want to test exactly how it's done I would frankly tie into the existing code and execute to get the results. You want to ensure the same code is rendering the same values as expected. This is more a unit test injected into the middle of a functional automation test. Frankly I would write a unit test or reuse one for mapping the exact code that does this and then call that from the automation test and the result would be the answer to that unit test assertion in the automation test.

If unit testing covers it, don't worry on automating the functional side of the stored procedure unless you can do it on the screen, but use what is already there as evidence and then manually test the gui. This seems more like duplicating effort, unless it's not unit tested already.

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.