Comments on: Database Unit Testing http://blog.straylightrun.net/2009/08/27/database-unit-testing/ Software, Technology, PHP Sun, 25 Dec 2011 01:09:52 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Frank Glandorfhttp://blog.straylightrun.net/2009/08/27/database-unit-testing/comment-page-1/#comment-2593 Frank Glandorf Mon, 31 Aug 2009 14:54:43 +0000 http://blog.straylightrun.net/?p=233#comment-2593 There are costs involved in maintaining sqlite and mysql but I can't quantify them. Small mysql installations seem easy to administer, especially if they are throw aways. If the unit tests are run on the same host as the db then the network traffic should be negligible. If you want a memory only db and avoid disk access, then try mysql's "memory" storage engine. http://dev.mysql.com/doc/refman/5.0/en/memory-storage-engine.html There are costs involved in maintaining sqlite and mysql but I can’t quantify them. Small mysql installations seem easy to administer, especially if they are throw aways. If the unit tests are run on the same host as the db then the network traffic should be negligible. If you want a memory only db and avoid disk access, then try mysql’s “memory” storage engine. http://dev.mysql.com/doc/refman/5.0/en/memory-storage-engine.html

]]> By: gerardhttp://blog.straylightrun.net/2009/08/27/database-unit-testing/comment-page-1/#comment-2565 gerard Sat, 29 Aug 2009 14:35:51 +0000 http://blog.straylightrun.net/?p=233#comment-2565 You could do that, but I guess the answer to that is 1) All databases require mainentenance, and that would be one more, while the SQLite database only exists while the test is running. And 2) now there is real network and disk operations, which will take longer the more tests you have, while SQLite runs completely in memory. I guess the answer is to use SQLite in production, which plenty of ppl do. You could do that, but I guess the answer to that is 1) All databases require mainentenance, and that would be one more, while the SQLite database only exists while the test is running. And 2) now there is real network and disk operations, which will take longer the more tests you have, while SQLite runs completely in memory.

I guess the answer is to use SQLite in production, which plenty of ppl do.

]]> By: Frank Glandorfhttp://blog.straylightrun.net/2009/08/27/database-unit-testing/comment-page-1/#comment-2554 Frank Glandorf Fri, 28 Aug 2009 15:45:48 +0000 http://blog.straylightrun.net/?p=233#comment-2554 It seems like a lot of extra work to develop under one database product and test under another. One could well spend time developing infrastructure and chasing bugs as a result of vendor differences. If one already has mysql installed, why not just create another database instance for testing? It seems like a lot of extra work to develop under one database product and test under another. One could well spend time developing infrastructure and chasing bugs as a result of vendor differences. If one already has mysql installed, why not just create another database instance for testing?

]]> By: gerardhttp://blog.straylightrun.net/2009/08/27/database-unit-testing/comment-page-1/#comment-2540 gerard Thu, 27 Aug 2009 19:14:36 +0000 http://blog.straylightrun.net/?p=233#comment-2540 Cool. I wonder if this is as simple as adding a startTransaction() in the setUp() method, and a rollback() in the tearDown()? Cool. I wonder if this is as simple as adding a startTransaction() in the setUp() method, and a rollback() in the tearDown()?

]]> By: Chris Nelsonhttp://blog.straylightrun.net/2009/08/27/database-unit-testing/comment-page-1/#comment-2539 Chris Nelson Thu, 27 Aug 2009 18:33:34 +0000 http://blog.straylightrun.net/?p=233#comment-2539 This is all fine, but eventually your database tests tend to get very slow. In the java and ruby worlds, we've moved to the idea of transactional test cases, which I've found to be a great thing. The basic concept is all your test case methods get run in their own transaction, which gets rolled back after each test. This way tests can insert, update, check the results, etc, all without actually changing the state of the database. I don't know if this is available already in PHP, but if not I'm sure it could be done. This is all fine, but eventually your database tests tend to get very slow. In the java and ruby worlds, we’ve moved to the idea of transactional test cases, which I’ve found to be a great thing. The basic concept is all your test case methods get run in their own transaction, which gets rolled back after each test. This way tests can insert, update, check the results, etc, all without actually changing the state of the database. I don’t know if this is available already in PHP, but if not I’m sure it could be done.

]]>