I love tests. If you have not worked with me, you have no idea how much I love them. They help me be lazy so that I do do more work with less time. It also helps that tests mean I can build a better product.
For the last couple of years, I have been writing integration tests in that the tests that I write for the UI layer go all the way down to the db. With unit tests, you are supposed to have mock objects for all dependencies. But here's the thing: I'm lazy and have not been sold on the idea of mocks for something like a db.
Why do I like integration tests? I have found many errors that I do not believe that I would have found with "unit tests". That and my perceived extra work with creating and managing mock objects. The disadvantages of integration tests?
1) You may be adding data to the db that wasn't intended
2) possible side effects from one test to another
3) slower!!!
# 3 is my biggest complaint right now. My test suite takes minutes to run. Seconds would be better. Less than 1 second would be best. Something that I think would help would be to have an in-memory database for Oracle. I've blogged about that before :-/ No luck finding one online tonight 'cause oracle.com seems to be down... (yikes!).
If you believe that "unit testing" as apposed to integration testing (with a unit testing framework) is the way to go, please comment on why. My mind is still open, I just have not seen an argument that has changed my mind and I am wondering if I am missing out on something.
Update: a co-worker pointed me to Oracle's TimesTen that will allow you to do in-memory testing. I have not tried it out yet, but I hope that there would be no difference in behaviour between TimesTen and 10g. One of the things that I have done with my tests is to make them run in a transaction and then just roll them back at the end of the test (by default). This solves all 3 problems. I am much happier now that I have done this. ;-)
I'm not sure if Oracle supports an in-memory database, however, I know that there are in-memory databases out there. If you have a proper database abstraction layer, and you haven't used too many of the proprietary things (PL/SQL) included in Oracle, it may not be too much work to switch one for the other. That being said, you still aren't testing on the real database, so it would be best to run you test scripts on the real thing, although it would be nice to not have to run the scripts actual database if you are experiencing major slowdowns due to running your test scripts.
ReplyDeleteThe other side of the coin is that RDBMS's do keep tables in memory. They look at the server load and decide for themselves what needs to be in memory, and what can be swapped out to the disc. SQL Server, has the DBCC PINTABLE command so that you can tell the database to permanently cache a table in memory. I would assume that Oracle has similar features. So, you could theoretically cache all your tables in memory, and hope your computer has enough memory to handle all this. If you're only running a test database, you may very well have enough memory. That being said, you'll probably also want to run your tests on a database about the same size as what you'll be running in production, or performance issues might not crop up until it's too late.