1

I apologise in advance if this question is too subjective but I'm struggling to find a good answer, probably as there is not really a correct answer to give.

I'm currently writing a database abstraction layer to unify the use of a single API throughout my applications. Possibly re-inventing the wheel but I'm mainly doing it for my specific need of certain Oracle functionality that will eventually be migrated away from Oracle.

For the Oracle driver I'm finding it difficult to test the object due to the lack of an OO API in PHP, so to test I need to touch the database. There seems to be two schools of thought on testing database functionality.

  1. Don't touch the database, mock it all away (obviously impossible without an OO API).
  2. Allow the functionality to run and therefore feature test rather than unit test.

My question is two fold, has anyone done this before and how did you handle testing? If you haven't had cause to do this before, what are your thoughts on how you would handle it and why?

2 Answers 2

1

If there is no way possible, set up a test database and have the test interact with it. Since this is communication layer, you shouldn't be doing all together all that much.

There is a way to mock PHP functions if you are using PHP 5.3 or later via namespacing. Basically, you place your code and test in the same namespace. Then in your test you can mock the function calls. PHP will check in your namespace and find the function and not call the internal function.

http://www.schmengler-se.de/-php-mocking-built-in-functions-like-time-in-unit-tests

This way you would be able to test your class, and mock the php internal functions and not have to touch any database.

1
  • I like this idea, I'm running integration tests that create a test schema and interact with it, but simpler unit tests would be nice as well so I'll look in to this Commented May 2, 2013 at 7:49
0

I've seen someone doing an automatically replace of all functions in a similar case before running his unit tests.

So first he reads all the code who should be tested, in your case searches for oci_*() functions and replaces them by my_oci_*() functions . You can then mock these my_oci_*() functions.

Another option could be to install a php version without the oci-support on your test environment, so the functions are not defined and you can implement/mock them on your own.

2
  • Interesting thought, so are you of the opinion that the tests should never connect to the database? Commented Apr 27, 2013 at 15:53
  • 1
    Unit tests should not connect to the database, feature tests can connect and to get the best test coverage you should build both types ;)
    – Tobias
    Commented Apr 27, 2013 at 15:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.