[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [pdf-devel] time module unit test cases
From: |
jemarch |
Subject: |
Re: [pdf-devel] time module unit test cases |
Date: |
Thu, 17 Apr 2008 20:52:32 +0200 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/23.0.60 (powerpc-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) |
Hello Anish.
Sorry for the delay i was little busy.
No problem! Thanks to dedicate your spare free time to this project :)
I will send unit test cases with documentation
Nice! Are you using the texinfo format to document the testcases, isnt
it?
>>Say we want to store the FEB 2 2008-01-01 12:00:00 IST date into
>>pdf_time_t. Since pdf_time_t is an opaque type I cannot access to it
>>implementation. Instead I fill the structure type pdf_time_cal_s with
>>appropriate values:
>> pdf_time_from_cal (my_time, my_time_cal);
>>Later on I would like to get the value of `my_time' out:
Thanks for the explanation. I thought in the same way but just wanted to
confirm it.
Ok.
Is it a good idea to have constructor at the time of creation of object
itself?
e.g *pdf_time_new** (*pdf_time_cal_s var*)
*
Generally we prefer to have parameterless "constructors" with
reasonable defaults.
I wanted to confirm one more thing, suppose i have created one object using
*pdf_time_dup**.
*So the contains of new object is similar to previous object. This test case
is not unit test case right as this is functional test case.
Say passing invalid object and see what is the behavior this can be unit
test case right?*
*
I dont fully understand you. In order to define unit test cases for
the `pdf_time_dup' function you should indeed use it. The fact that it
creates a new variable containing the same values as the parameters
do not invalidate it as a unit test case.
Passing an invalid object to the function (an invalid pointer) will
surely cause the application to crash. It is generally not possible in
C to determine if a pointer is a "valid" one (if it points to
appropiately allocated _and_ appropriately initialized memory). Even
if you expect a crash (and test for the presence of a crash in the
process) you may be dissapointed: the application may survive if the
garbage contained in the pointer points to a valid memory
address. So it is not useful to define negative unit tests with
invalid pointers.
I hope that helps.
--
Jose E. Marchesi <address@hidden>
<address@hidden>
GNU Spain http://es.gnu.org
GNU Project http://www.gnu.org
- [pdf-devel] time module unit test cases, anish patil, 2008/04/07
- Re: [pdf-devel] time module unit test cases, jemarch, 2008/04/07
- Re: [pdf-devel] time module unit test cases, anish patil, 2008/04/10
- Re: [pdf-devel] time module unit test cases, jemarch, 2008/04/10
- Re: [pdf-devel] time module unit test cases, anish patil, 2008/04/17
- Re: [pdf-devel] time module unit test cases,
jemarch <=
- Re: [pdf-devel] time module unit test cases, gerel, 2008/04/17
- Re: [pdf-devel] time module unit test cases, gerel, 2008/04/17
- Re: [pdf-devel] time module unit test cases, jemarch, 2008/04/18
- Re: [pdf-devel] time module unit test cases, gerel, 2008/04/18
- Re: [pdf-devel] time module unit test cases, gerel, 2008/04/18
- Re: [pdf-devel] time module unit test cases, jemarch, 2008/04/19
- Re: [pdf-devel] time module unit test cases, jemarch, 2008/04/19
- Re: [pdf-devel] time module unit test cases, gerel, 2008/04/19
- Re: [pdf-devel] time module unit test cases, jemarch, 2008/04/20
- Re: [pdf-devel] time module unit test cases, Eder, 2008/04/20