
>
> Generally I find it's good to look at examples that work.  For 
> examples of packages using tests, look at source packages on CRAN.  
> Run the tests on them (using R CMD check), and see what gets produced.
>
Do you have the name of a package that use it ? I try the 10 first 
package, and 10 other at random, but none of them use tests...
>>> Create tests/myPack.R with those lines in it plus lines to actually 
>>> run the code.
>> Does it mean that each time I change the code, I will have to change 
>> it twice, once in R/ and once in tests/
>
> There shouldn't be any duplication.  Just put tests in the tests 
> directory.  That code will be run with your package loaded when you 
> run R CMD check.  If it fails, your package will fail the check.
Sorry, this is very unclear to me. What do you call "tests" that I have 
to put in the tests directory ?
Let's take an example : My package is a single function that take the 
square of only positive number. I make a mistake and I forget that it 
has to reject negative number :

sq <- function(x){return(x2)}

Fortunately, I am very conscientious (!) and I did prepare some test :
- sq(2) should be 4
- sq(Inf) should be Inf
- sq(-2) should be NA (on this example, this last test will fail)

At his point :
sq <- function(x){return(x2)} is in R/main.r

1) What shall I put in the test file ?
2) Cann't I build a Rout file containning the expected results 4 ; Inf; 
NA ?

Thanks for helping

Christophe
>>   If the code generates errors, your test will fail.  If you want to 
>> see reports of changes to the output, also include 
>> tests/myPack.Rout.save with the known correct versions of the output.
>>
> What should the Rout.save looks like ? I mean, what is the syntax of 
> this file ?

It should just be a copy of the Rout file produced from a previous 
trusted run.  R CMD check will ignore certain differences (like changes 
to the date or R version at the top of the file), but will report on 
others.

Duncan Murdoch

	[[alternative HTML version deleted]]

