Re: [commits] Horde branch master updated. 9ac03eb9986f297753bbd15fd4191f0fa3f44c5b

Quoting Michael J Rubinsky <[email protected]>:

> Quoting Michael M Slusarz <[email protected]>:
>
>
>> commit dfd1041a4c146d8754686cd9530e9fe2a44054aa
>> Author: Michael M Slusarz <[email protected]>
>> Date:   Thu Jan 22 02:45:18 2015 -0700
>>
>>    Fix tests
>>
>>    Can't use serialized objects, since there is no guarantee (like here)
>>    that the internals won't change.
>>
>> framework/ActiveSync/test/Horde/ActiveSync/ImapAdapterTest.php    |  
>>    7 ++--
>> .../ActiveSync/test/Horde/ActiveSync/MessageBodyDataTest.php      |  
>>    8 ++++-
>> 2 files changed, 11 insertions(+), 4 deletions(-)
>>
>> http://github.com/horde/horde/commit/dfd1041a4c146d8754686cd9530e9fe2a44054aa
>
>
> These are Horde_Imap_Client_Fetch_Results objects. Since these  
> objects contain internal Horde_Mime_Part and Horde_Mime_Header  
> objects, perhaps these objects (or Horde_Imap_Client_Data_Fetch  
> objects) should be marked not serialize-able.

That class is serializable.  (Thought I had unit tests for this but I  
didn't.  Just created and this claim has been verified).

I think you are confusing a serializable representation of an object  
with data archiving.  Serializing is designed to completely and  
accurately represent the internal state of an object within the  
current PHP running environment.  There is no guarantee it can be  
unserialized in the future.  (Example: imagine an object storing some  
data internally that is gzip compressed.  If PHP is updated to a  
version without gzip, that serialized data is no longer recreateable.)

   In other words: serializing is a form of caching: it can't be used  
to archive any important data within the object.  There needs to be  
some sort of export function for that.

I'm not sure why you are serializing in this test case.  I'm assuming  
that maybe there is/was a bug with the way an activesync class was  
interacting with an Imap Client object at a particular former revision.

If that's the case, it seems like there is 3 options:

1. You need to recreate that object explicitly via instantiation  
before testing. Not sure if the bug will manifest itself in  
current/future revisions of the Imap_Client related object though.
2. You need to mock exactly what is wrong with the Imap_Client object  
so you can exactly control the behavior of that object in the future.
3. You need to import the entire environment necessary, i.e. copy of  
the necessary PHP files needed locally to the test unit, to recreate  
that object, exactly as it exists at a current revision.

michael

___________________________________
Michael Slusarz [[email protected]]

-- 
dev mailing list
Frequently Asked Questions: http://wiki.horde.org/FAQ
To unsubscribe, mail: [email protected]