This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
Hello there. You can create JUnit tests easily to test your database functionality (including regarding concurrency). I don't have the links with me, but there are a few threads in this forum that show examples of tests. They are indeed helpful.
You can use Junit for testing core functionality of the application.
I hope giving some focus on JUNIT testcases will be helpful.
Some of the good Practices of Junit:
1) A Junit should never test the APIs that are already existing. Eg: If there is an EntityBean which persists some data into Database table, then there is no need to write JUNIT test case to test that EntityBean. Because JUNIT SHOULD TEST APPLICATION functionality. SUN may have already tested the methods of EntityBean for persistance. We do not have to again test those API
2) Avoid JUNIT test changing the Database. Even if for your functionality, some data needs to be changed in the Database, and you want to test it; a Junit test case may change the DB but later the changes are to be rolled back.
3) Try to avoid a Junit test case interacting with resources which deals with expensive operations. Eg: while testing functionality related to FTP, while testing DB etc. You can use mock objects(which does the dependency injection) to deal with these kind of situations.
4) "TEST FIRST CODE NEXT" . This is one of the most important points in Test Driven Development. If one follows this rule, one's code will be well organised and garnished.
Uses: ===== 1) If one uses JUNIT test cases, One would be confident of his/her functionality. It is a good practice to run all the JUNIT test cases before a developer does the checkin of the code so that his/her recent code would not break the already existing functionality.
Finally every good thing will have a drawback.
Excessive use of Junits 1)Consumes a good amount of development time.Some times you feel, amount of time spent on writing test cases is more than your actual development. 2) Causes tight coupling with the code.