pdf-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[pdf-devel] Check in win32 (was Re: [Check-users] using Check with Autot


From: Aleksander Morgado
Subject: [pdf-devel] Check in win32 (was Re: [Check-users] using Check with Autotest (was Re: Projects using Check - GNUpdf))
Date: Mon, 2 Feb 2009 09:59:09 +0100

Hi all,

Now that it comes to both lists, we may also start using directly the
check library in our win32 tests, as the port seems ready for mingw
(am I right?), instead of the built-in 'no-check' replacement in GNU
PDF.

Cheers,
-Aleksander


On Sun, Feb 1, 2009 at 9:55 PM, Chris Pickett
<address@hidden> wrote:
> Hi Sylvain,
>
> That's great, I've added GNUpdf to our list, thanks for letting us know.
>
> I looked at your testing architecture document a little.  At some level
> you're probably going to want something higher level than Check.  If
> you're using the Autotools, I would recommend the simple but effective
> Autotest system.  In my own work, I actually have one Autotest test for
> each module in the library I'm developing.
>
> https://svn.sable.mcgill.ca/sable/spmt/libspmt/tests/Makefile.am
> https://svn.sable.mcgill.ca/sable/spmt/libspmt/tests/Makefile.tests.am
>
> I also silenced the standard Autotest output, so that I get:
>
> $ make check
> [...gcc commands...]
>
> =====================
>  All 48 tests passed
> =====================
>
> with the above message coloured green, or:
>
> $ make check
> [...gcc commands...]
>
> FAIL: buffer
> ============
> Running suite(s): buffer
> ../src/buffer.c:76: failed assertion `buffer != NULL'
> 97%: Checks: 39, Failures: 1, Errors: 0
> buffer.c:407:F:core:check_spmt_buffer_BRbit5_HWbit5_DEPENDENCE:0:
> Assertion '(DEPENDENCE () == 0)' failed
>
> ==================================================
>  1 of 48 tests failed
>  Please report to chris.pickett AT mail.mcgill.ca
> ==================================================
>
> with the above message coloured red.  I find this is much more easy for
> me to deal with when something goes wrong, and avoids two problems:
>
> 1) falling back to old habits and writing tests where I manually check
> the output each time
>
> 2) having to scroll back through a huge list of tests when something
> goes wrong to find what it is that happened.
>
> Not sure if this is useful information for you, but maybe one of the
> other subscribers is interested.
>
> Cheers,
> Chris
>
> Sylvain Beucler wrote:
>> Hi,
>>
>> At the invitation of the project homepage, I inform you that the
>> GNUpdf project uses 'check' for unit testing :)
>>
>> The GNUpdf project is developing a free, high-quality library that
>> implement the PDF file format (ISO 32000) - and hence need to assert
>> the quality and correctness of the library using an aggressive testing
>> strategy nick-named "Torture Chamber".
>>
>> (more info at:)
>> http://www.gnupdf.org/manuals/gnupdf-hg.html/Testing-the-library.html
>>
>> Cheers!
>>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Check-users mailing list
> address@hidden
> https://lists.sourceforge.net/lists/listinfo/check-users
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]