Why would you need the salt as stored in the database? Sounds like a dubious approach to unit testing. Think of what behavior you're expecting from the method given known inputs. Because you know what the input values are, you should also know what your expected output is. That's all you need for unit testing. Basically, find input values that would test all edge cases, normal cases, and exceptional cases.
That wasn't my question. I asked why do you need to know the salt "as stored in the database"? Who cares where the salt value comes from? Just make one up! A unit test has to be repeatable. In order for it to be repeatable, you need to know exactly what you're using as input values for the test.
Say your salt is "123456789mySaltValue" -- this is a known value you can use for a unit test. To see if your method works properly, you'll need to know what your expected output is. What return value would you expect from the method if you gave "mySecretPassphrase" as the password to hash and "123456789mySaltValue" as the salt? That is essentially your unit test:
I have issue since i am saving salt as a byte array in DB. So when i am testing hashing function , i need t give the save salt to get the same hash value. But in DB it saves as a byte array which is not readable. I can get the hash password from the directly for a give user, but not the salt value. I am using SQL server, so the column type of the salt is varbinary. How can i get the exact salt value for a given user?
One clarification: I am going by Michael Feathers' definition of a "unit test," namely that anything that touches the database is NOT a unit test.
Before you save the salt value to the DB as a byte array, what type of value do you have? I would assume a String but the actual type is not relevant to my point which is that anything that goes on between having the value in memory and saving that value in the DB as a byte array is outside the realm of concern of unit testing. Just write your unit test as though the translation from DB byte array to whatever native Java type has already occurred. Again, the type used to save the value in the DB is irrelevant to the unit test so why bother? Treat that as a separate problem.