PHP Developers Network

A community of PHP developers offering assistance, advice, discussion, and friendship.
 
Loading
It is currently Sat Jul 21, 2018 9:54 pm

All times are UTC - 5 hours




Post new topic Reply to topic  [ 5 posts ] 

Can a unit test touch a database and still be considered a unit test
Yes 50%  50%  [ 1 ]
Yes, only if you are using data mapper pattern and you are testing one of your mappers 0%  0%  [ 0 ]
Yes, if the system under test implements active record or has inline SQL 0%  0%  [ 0 ]
Yes, if the system under test is coupled to a database by design 50%  50%  [ 1 ]
No, never 0%  0%  [ 0 ]
Total votes : 2
Author Message
PostPosted: Wed Nov 18, 2009 2:04 pm 
Offline
DevNet Master

Joined: Wed Feb 11, 2004 4:23 pm
Posts: 4872
Location: Palm beach, Florida
A lot of respectable people tell you if a test touched a database, it is not a unit test, but I tend to disagree. I feel that it depends on what you are writing unit tests for.I think If you are unit testing a database adapter it should touch the database. What is devnet's thoughts?


Top
 Profile  
 
PostPosted: Fri Nov 20, 2009 6:34 am 
Offline
DevNet Master
User avatar

Joined: Mon Sep 19, 2005 6:24 am
Posts: 3587
Location: London
In PHP it can be difficult to test a data accessor without touching the database (can't mock mysql_connect() etc) but that is the only valid unit test which is allowed to touch the DB in my opinion. For everything else, it can be mocked, even if all you do is simply create a wrapper for the mysql_* functions, and doing so specifically just for mocking/testing purposes is utterly justifiable and a must-do. :)


Top
 Profile  
 
PostPosted: Fri Nov 20, 2009 3:36 pm 
Offline
DevNet Master

Joined: Wed Feb 11, 2004 4:23 pm
Posts: 4872
Location: Palm beach, Florida
Is there a database mocking library? That is a good idea (wrapping the mysql functions, and an easy refactoring at that) but without touching the actual database how would you try to avoid over-specified software? I guess there is no utopia and an in memory database is the best you'll get huh?

My extension has a ton of dependencies on other code that would be impossible to mock (the API in question is not stable).

My other thing was, I always test my data mappers, which are in my model layer, and the tests run as part of my unit tests. From the reading I've been doing it made it seem like I'm doing something wrong.

I did however start putting my Test files in the same paths as my production code, which is probably another topic, but boy does that have a ton of benefits.


Top
 Profile  
 
PostPosted: Wed Dec 02, 2009 8:07 pm 
Offline
DevNet Evangelist

Joined: Tue Dec 21, 2004 6:00 pm
Posts: 6267
Location: Winnipeg
Quote:
A lot of respectable people tell you if a test touched a database, it is not a unit test, but I tend to disagree


I think it depends on how you view "unit testing" fundementally. Personally I see it as being different from BDD (a discussion I had years ago with Maugrim can be found for greater detail) in that TDD is more focused on testing the state/result of a SUT, whereas BDD is more oriented towards testing behaviors of an object, not as much with the result or state.

If your doing BDD (or TDD if your die hard I suppose) you are probably far more focused on design and thus behaviors and so your models probably use that additional abstraction layers to decouple the model from a data source, mocking the data store objects and thus focusing more on the behavior of the model, as opposed to the returned results, which is the case in classic testing, as opposed to mockist testing:

http://martinfowler.com/articles/mocksArentStubs.html

If you are less concerned with design and perhaps implement your models with a crude interpretation of table data gateway (by this I mean manually constructing the SQL query in the model and passing it to a DB abstraction layer query/execute method) you are far more likely to see benefit in testing the state of the method, rather than it's behavior, as business logic, etc is probably a series of conditionals which use local variables and are impossible to set expectations for.

On the other hand, if you are really focused on keeping your design OO then you probaly use a few objects to abstract the domain layer into logical peices, such as validation objects, data mappers, logging, etc. You probably promote inversion of control religiously and can therefore `test`the behavior of methods more easily than you did testing `state` back when you practiced more traditional or classical TDD.

This has been a distinction for me between the two methodolgoies, other than simply saying `Ìf you do TDD properly your already doing BDD` -- despite what the invetor Dave Astels says. :P

Cheers,
Alex


Top
 Profile  
 
PostPosted: Wed Dec 02, 2009 10:38 pm 
Offline
DevNet Master

Joined: Wed Feb 11, 2004 4:23 pm
Posts: 4872
Location: Palm beach, Florida
PCSpectra wrote:
On the other hand, if you are really focused on keeping your design OO then you probaly use a few objects to abstract the domain layer into logical peices, such as validation objects, data mappers,

Well yeah, even if the logic is encapsulated in a DAO, you still gotta test the DAO, and the main confusion is wether that test is really a "unit" test or a functional test.

I have started using the When Then pattern

testWhenNoConfigurationThenThisHappens
testWhenThatConfigurationSomethingElseHappens
testWhenSomeOtherCOnfigurationTHatHappens
etc...


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group