|
From: João H. F. <jo...@gm...> - 2009-11-12 23:46:52
|
Thanks, I will start the job. 2009/11/12 Markus Hoenicka <mar...@mh...>: > Markus Hoenicka writes: > > I'll have to rewrite the accessor functions, and add new ones to make > > the expected values available to calling functions. Then we'd have to > > I've finished adding the accessor functions. Now we should have all > the infrastructure available to rewrite the tests. These should use > values taken from the structures via the accessor functions instead of > hardcoded values. > > Once that is done, I'd like to rearrange the code in test_dbi.c to > separate driver-specific code from non-specific code. This way we > could draw a line claiming "no driver-specific changes required below > this line" to make adding new drivers more pleasant. > > regards, > Markus > > -- > Markus Hoenicka > http://www.mhoenicka.de > AQ score 38 > -- ----------------------------------------------------------- João Henrique Freitas - joaohf_at_gmail.com Campinas-SP-Brasil BSD051283 LPI 1 http://www.joaohfreitas.eti.br |
|
From: João H. F. <jo...@gm...> - 2009-11-24 00:03:48
|
Hi
I am using the accessor funcions to fetch the values. I think two
member of struct FIELDINFO need to be more big.
struct FIELDINFO {
char name[32];
unsigned short type;
unsigned int attrib;
union {
long long int int_val;
unsigned long long int uint_val;
double double_val;
char string_val[48];
} expect_val;
long long expect_as_longlong;
char expect_as_string[48];
};
Thanks.
>
>
> 2009/11/12 Markus Hoenicka <mar...@mh...>:
>> Markus Hoenicka writes:
>> > I'll have to rewrite the accessor functions, and add new ones to make
>> > the expected values available to calling functions. Then we'd have to
>>
>> I've finished adding the accessor functions. Now we should have all
>> the infrastructure available to rewrite the tests. These should use
>> values taken from the structures via the accessor functions instead of
>> hardcoded values.
>>
>> Once that is done, I'd like to rearrange the code in test_dbi.c to
>> separate driver-specific code from non-specific code. This way we
>> could draw a line claiming "no driver-specific changes required below
>> this line" to make adding new drivers more pleasant.
>>
>> regards,
>> Markus
>>
>> --
>> Markus Hoenicka
>> http://www.mhoenicka.de
>> AQ score 38
>>
>
>
>
> --
> -----------------------------------------------------------
> João Henrique Freitas - joaohf_at_gmail.com
> Campinas-SP-Brasil
> BSD051283
> LPI 1
> http://www.joaohfreitas.eti.br
>
--
-----------------------------------------------------------
João Henrique Freitas - joaohf_at_gmail.com
Campinas-SP-Brasil
BSD051283
LPI 1
http://www.joaohfreitas.eti.br
|
|
From: Markus H. <mar...@mh...> - 2009-11-24 08:25:29
|
Hi João,
please change these values as needed. I just took wild guesses from
looking over the code real quick, so I may have missed some of the
longer strings.
regards,
Markus
Quoting João Henrique Freitas <jo...@gm...>:
> Hi
>
> I am using the accessor funcions to fetch the values. I think two
> member of struct FIELDINFO need to be more big.
>
> struct FIELDINFO {
> char name[32];
> unsigned short type;
> unsigned int attrib;
> union {
> long long int int_val;
> unsigned long long int uint_val;
> double double_val;
> char string_val[48];
> } expect_val;
> long long expect_as_longlong;
> char expect_as_string[48];
> };
>
>
>
> Thanks.
>
>>
>>
>> 2009/11/12 Markus Hoenicka <mar...@mh...>:
>>> Markus Hoenicka writes:
>>> > I'll have to rewrite the accessor functions, and add new ones to make
>>> > the expected values available to calling functions. Then we'd have to
>>>
>>> I've finished adding the accessor functions. Now we should have all
>>> the infrastructure available to rewrite the tests. These should use
>>> values taken from the structures via the accessor functions instead of
>>> hardcoded values.
>>>
>>> Once that is done, I'd like to rearrange the code in test_dbi.c to
>>> separate driver-specific code from non-specific code. This way we
>>> could draw a line claiming "no driver-specific changes required below
>>> this line" to make adding new drivers more pleasant.
>>>
>>> regards,
>>> Markus
>>>
>>> --
>>> Markus Hoenicka
>>> http://www.mhoenicka.de
>>> AQ score 38
>>>
>>
>>
>>
>> --
>> -----------------------------------------------------------
>> João Henrique Freitas - joaohf_at_gmail.com
>> Campinas-SP-Brasil
>> BSD051283
>> LPI 1
>> http://www.joaohfreitas.eti.br
>>
>
>
>
> --
> -----------------------------------------------------------
> João Henrique Freitas - joaohf_at_gmail.com
> Campinas-SP-Brasil
> BSD051283
> LPI 1
> http://www.joaohfreitas.eti.br
>
--
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38
|
|
From: João H. F. <jo...@gm...> - 2009-12-06 18:05:25
|
Hi, See: http://my.cdash.org/viewTest.php?buildid=40388 http://my.cdash.org/viewTest.php?buildid=40389 I am fight with double tests and null strings. I created the length member to struct FIELDINFO and create some special fields like '_*' which help to test some string functions. Please show me your idea about: "rearrange the code in test_dbi.c to separate driver-specific code from non-specific code". In the test framework exists some tests written to specific driver like: if (mysql) do... else if (pgsql) do... The accessors functions and struct FIELDINFO helps to reduces it. I will setup my environment to test mysql, pgsql and firebird. But I think it is not will be a problem. Thanks. -- ----------------------------------------------------------- João Henrique Freitas - joaohf_at_gmail.com Campinas-SP-Brasil BSD051283 LPI 1 http://www.joaohfreitas.eti.br |
|
From: Markus H. <mar...@mh...> - 2009-12-06 23:37:27
|
Quoting João Henrique Freitas <jo...@gm...>: > Please show me your idea about: "rearrange the code in test_dbi.c to > separate driver-specific code from non-specific code". > > In the test framework exists some tests written to specific driver like: > > if (mysql) > do... > else if (pgsql) > do... > Hi, the idea is simply to move all functions that contain code like the one cited above to the top of the file, and all functions which are driver-independent (either by nature, or by means of the accessor functions) below a line reading "no driver-specific stuff below". I often do this in scripts to make clear where to fiddle with the code and where not, if customizations are required. I figured this might ease the task of adding drivers or modifying driver tests. As for the rest, I'll have a look at your work as soon as time permits. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 |