From ligges at statistik.tu-dortmund.de  Thu May 17 16:59:13 2012
From: ligges at statistik.tu-dortmund.de (Uwe Ligges)
Date: Thu, 17 May 2012 16:59:13 +0200
Subject: [Rd] test suites for packages
In-Reply-To: <1337266373.18928.2.camel@brian-rcg>
References: <CAMi=pg6MRN9BxGQz4C=t6x=s1nGKGp_nLRyRwe6zSmKfs1_whA@mail.gmail.com>
	<4FB50C02.5050803@statistik.tu-dortmund.de>
	<1337266373.18928.2.camel@brian-rcg>
Message-ID: <4FB51241.90209@statistik.tu-dortmund.de>



On 17.05.2012 16:52, Brian G. Peterson wrote:
> On Thu, 2012-05-17 at 16:32 +0200, Uwe Ligges wrote:
>> Yes: R CMD check does the trick. See Writing R Extension and read
>> about a package's test directory. I prefer frameworks that do not
>> obfuscate failing test results on the CRAN check farm (as most other
>> frameworks I have seen).
>
> Uwe:  I don't think that's completely fair.  RUnit and testthat tests
> can be configured to be called from the R package tests directory, so
> that they are run during R CMD check.
>
> They don't *need* to be configured that way, so perhaps that's what
> you're talking about.


I am talking about the problem that relevant output of test failures 
that may help to identify the problem is frequently not shown in the 
output of R CMD check when such frameworks are used - that is a major 
nuisance for CRAN automatisms.

If additional configuration steps are required, fine, but then package 
maintainers seem to forget about that step. We do not have the time to 
tell hundreds of package maintainers how to configure their preferred 
test framework (whatever it is).

Best,
Uwe



[Rd] test suites for packages
Uwe Ligges