From mdowle at mdowle.plus.com  Thu May 17 17:56:11 2012
From: mdowle at mdowle.plus.com (Matthew Dowle)
Date: Thu, 17 May 2012 15:56:11 +0000
Subject: [Rd] test suites for packages
References: <CAMi=pg6MRN9BxGQz4C=t6x=s1nGKGp_nLRyRwe6zSmKfs1_whA@mail.gmail.com>
	<4FB50C02.5050803@statistik.tu-dortmund.de>
	<1337266373.18928.2.camel@brian-rcg>
	<4FB51241.90209@statistik.tu-dortmund.de>
Message-ID: <loom.20120517T174345-994@post.gmane.org>

Uwe Ligges <ligges <at> statistik.tu-dortmund.de> writes:
> 
> 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.

Not sure, but could it be that in some cases the output of test failures is 
there, but chopped off since CRAN displays the 13 line tail? At least that's 
what I've experienced, and reported, and asked to be increased in the past. 
Often the first error causes a cascade, so it's the head you need to see, not 
the tail. If I've got that right, how about a much larger limit than 13, say 
1000. Or the first 50 and last 50 lines of output.

Matthew



[Rd] test suites for packages
Matthew Dowle