cvs: pear /MDB2/tests MDB2_usage_testcase.php

Justin Patrin wrote:
> justinpatrin		Sat Aug 19 22:15:26 2006 UTC
> 
>   Modified files:              
>     /pear/MDB2/tests	MDB2_usage_testcase.php 
>   Log:
>   Remove incorrect test case for field case without
portability

There is the question of how to deal with test cases that
essentially 
just illustrate the default behavior of the given RDBMS
without any 
portability handling. Obviously these tests may fail even
though there 
is nothing broken in the driver, simply because the RDBMS
works 
differently by default as is expected in MDB2 for maximum
portability.

Leaving them in has the advantage that users can better
realize what it 
means if they disable the given portability setting. But has
the 
disadvantage of potentially confusing users that the driver
is broken.
I am sort of unsure how to approach this.

Maybe the better solution would be to remove tests with the
portability 
settings disabled and instead work towards documenting this
inside the 
manual. However someone would need to add this
documentation, and what 
should happen in the mean time with the tests?

regards,
Lukas

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Lukas Kahwe Smith wrote:

> Justin Patrin wrote:
>> justinpatrin        Sat Aug 19 22:15:26 2006 UTC
>>
>>   Modified files:                  /pear/MDB2/tests
   
>> MDB2_usage_testcase.php   Log:
>>   Remove incorrect test case for field case without
portability
> 
> There is the question of how to deal with test cases
that essentially 
> just illustrate the default behavior of the given RDBMS
without any 
> portability handling. Obviously these tests may fail
even though there 
> is nothing broken in the driver, simply because the
RDBMS works 
> differently by default as is expected in MDB2 for
maximum portability.
> 
> Leaving them in has the advantage that users can better
realize what it 
> means if they disable the given portability setting.
But has the 
> disadvantage of potentially confusing users that the
driver is broken.
> I am sort of unsure how to approach this.
> 
> Maybe the better solution would be to remove tests with
the portability 
> settings disabled and instead work towards documenting
this inside the 
> manual. However someone would need to add this
documentation, and what 
> should happen in the mean time with the tests?

In order to end another monolog of mine on MDB2:
I have pondered some more .. and users that want to find out
what breaks 
if they disable portability options, they can just specify
the given 
portability setting in their test_setup.php

regards,
Lukas

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Hey Lukas:

On Sun, Aug 20, 2006 at 12:22:41PM +0200, Lukas Kahwe Smith
wrote:
> 
> There is the question of how to deal with test cases
that essentially 
> just illustrate the default behavior of the given RDBMS
without any 
> portability handling.

It's not just illustrative.  It's important to test that
the expected 
default behavior is actually happening.  For example, say I 
inadvertently put in some portability code where I
shouldn't have.  
There should be a test showing that goof.

Isn't it possible to include expected values for each DMBS?

Thanks,

--Dan

-- 
 T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M
P A N Y
            data intensive web and database programming
                http://www.Analy
sisAndSolutions.com/
 4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335 f:
718-854-0409

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Daniel Convissor wrote:

> Hey Lukas:
> 
> On Sun, Aug 20, 2006 at 12:22:41PM +0200, Lukas Kahwe
Smith wrote:
>> There is the question of how to deal with test
cases that essentially 
>> just illustrate the default behavior of the given
RDBMS without any 
>> portability handling.
> 
> It's not just illustrative.  It's important to test
that the expected 
> default behavior is actually happening.  For example,
say I 
> inadvertently put in some portability code where I
shouldn't have.  
> There should be a test showing that goof.
> 
> Isn't it possible to include expected values for each
DMBS?

Not sure I understand what you are saying. MDB2 expects
things to be 
portable. The test suite aims to cover this. It runs through
most of the 
API, including some edge cases, and compares the actual with
the 
expected data.

The question was about if I should also have tests where the
necessary 
portability features are disabled which lead to inconsistent
behavior 
between RDBMS. All these tests would illustrate would be for
example:

RDBMS xyz does not automatically RTRIM data coming from a
CHAR field.
RDBMY abc does not convert empty strings to NULL.

However like I said if people are interested in this they
can just run 
the test suite with the portability option set to
MDB2_PORTABILITY_NONE 
and check which test cases fail.

regards,
Lukas

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php