Well it really depends what kind of test you are doing. If it just a unit test I will typically mock the repository and return whatever value I want for my test case. In this case the database is never actually called. Now if you are looking for more of an integration test case and you want to actually execute your procedures, you would have to use an embedded database. Derby seems to have support for functions and stored procedures.
Note that when you do something like this your goal should not be to test the stored procedure, as there is no guarantee its going to behave the same on your test case with the embedded DB as it does in your production DB. This would be more a use case for functional testing.