6

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?

Thanks

Improve this question
4
  • 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 ♦
    Commented Mar 12, 2017 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
    Commented Mar 12, 2017 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
    Commented Mar 13, 2017 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
    Commented Mar 13, 2017 at 6:28

3 Answers 3

Reset to default
1

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.

Improve this answer
1

A stored procedure is an API into the datastore. As such it's fine to call it directly from your tests.

How it's called won't make that much difference in terms of test coverage. Call it in the easiest way possible right now to get your tests working. Calling it outside of the normal code will allow you to pass in values that normally might not be possible as well.

Improve this answer
0

Devise a query that returns the Initial Condition data from your testbed (probably captures a range of data, essentially a report)

  • run the query
  • save the query results

Run the parameterized Sproc - note the parms

  • run the same query
  • save the result

Compare the before / after results

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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