Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

migrated from stackoverflow.com Apr 27 '13 at 11:20

This question came from our site for professional and enthusiast programmers.

2 Answers 2

up vote 1 down vote accepted

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.

share|improve this answer
    
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 –  happyaccidents May 2 '13 at 7:49

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.

share|improve this answer
    
Interesting thought, so are you of the opinion that the tests should never connect to the database? –  happyaccidents Apr 27 '13 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 Zander Apr 27 '13 at 15:56

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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