http://www.turnleafdesign.com/ramblings-should-unit-tests-talk-to-a-data-source Ramblings of a junior developer Thu, 12 Nov 2009 19:56:08 -0700 http://wordpress.org/?v=2.8.5 hourly 1 http://www.turnleafdesign.com/ramblings-should-unit-tests-talk-to-a-data-source/comment-page-1#comment-404 Mocking JDBC Connections with MockRunner | Turnleaf Design Wed, 11 Nov 2009 05:56:44 +0000 http://www.turnleafdesign.com/?p=280#comment-404 [...] its data source. I decided to do some investigating into his claims, you can check out my findings here. I was however intrigued none the less and started looking for a tool that would allow me to easily [...] [...] its data source. I decided to do some investigating into his claims, you can check out my findings here. I was however intrigued none the less and started looking for a tool that would allow me to easily [...]

]]> http://www.turnleafdesign.com/ramblings-should-unit-tests-talk-to-a-data-source/comment-page-1#comment-401 rado Mon, 09 Nov 2009 19:36:25 +0000 http://www.turnleafdesign.com/?p=280#comment-401 Go check out the <a href="http://www.unitils.org/" rel="nofollow">untils.org</a> site and use it, they have a lot of guidelines and help for testing against a database. A "unit test" that hits a database is what I call an integration test. Integration tests are very useful, especially when you want to test that your database interaction is correct. So if you are developing a new database query, what you want is to test that your ORM mapping is correct and you can only do that by hitting the real database, a mock does not substitute. When you have functionality you will find it easier to mock the database away at the persistence layer. By mocking CustomerPersistence.findCustomer(int id) you can create a unit test that depends on it. In that case you are isolating just the unit you are working on which is what I call a "unit test". Go check out the untils.org site and use it, they have a lot of guidelines and help for testing against a database. A “unit test” that hits a database is what I call an integration test. Integration tests are very useful, especially when you want to test that your database interaction is correct. So if you are developing a new database query, what you want is to test that your ORM mapping is correct and you can only do that by hitting the real database, a mock does not substitute. When you have functionality you will find it easier to mock the database away at the persistence layer. By mocking CustomerPersistence.findCustomer(int id) you can create a unit test that depends on it. In that case you are isolating just the unit you are working on which is what I call a “unit test”.

]]> http://www.turnleafdesign.com/ramblings-should-unit-tests-talk-to-a-data-source/comment-page-1#comment-396 Developer Art Thu, 05 Nov 2009 14:28:24 +0000 http://www.turnleafdesign.com/?p=280#comment-396 I've just had an idea. Having your mocks fully support various database isolation levels can occupy you for months and years to come. That's probably one scenario when even buying an extra test database server would be better than wasting time and money on a developer trying to implement this support in a mock. I’ve just had an idea. Having your mocks fully support various database isolation levels can occupy you for months and years to come. That’s probably one scenario when even buying an extra test database server would be better than wasting time and money on a developer trying to implement this support in a mock.

]]>