From mariotomo at gmail.com  Sat Mar  3 09:56:04 2012
From: mariotomo at gmail.com (Mario Frasca)
Date: Sat, 3 Mar 2012 09:56:04 +0100
Subject: [Rd] seeing feedback when R CMD check pkg runs unit tests.
In-Reply-To: <4F510044.80600@gmail.com>
References: <1330703385.2502.98.camel@nens-lt-92>
	<4F510044.80600@gmail.com>
Message-ID: <20120303095604.74bdbb05@zorapide>

On Fri, 02 Mar 2012 12:15:48 -0500
pgilbert902 at gmail.com (Paul Gilbert) wrote:

> Mario
> 
> [...] Examples only need to run, but in tests/ you can
> do things like
> 
> if( 2*2 != 4 ) stop("arithmatic is messed up.")
> 

problem is: when you do a stop, you stop, meaning you do not run
subsequent tests.  the nice part of unit testing is that you have a
complete report of all failing parts, not just the first one.

but what you write, I would translate it into:

one script -the current one- to execute all tests (and it has to
succeed, in the sense it has to perform all tests and say it managed to
produce a report).

one script -which I did not yet write- to examine the complete
test report of the former one and inform `R CMD check` (the user)
whether anything went wrong in the unit tests.

WARNING would be bad enough if there are failing tests.

do you know how I can emit a NOTE from a test script?
I sometimes use disabled tests as a reminder of things that still have
to be done, but if I associate them to a WARNING or ERROR, r-forge will
not allow me to release the module.

> You may be able to get similar results from RUnit or svUnit, it would 
> just be a question of passing the stop() and warnings() back to the
> top level in the script file in tests/. If you don't do that, as you 
> observed, R CMD check thinks the unit testing worked fine, it did its 
> job and found the errors.

exactly.  this made me thing of splitting the task in two parts.
thanks, I will try that and come back here next week. (and document it
on the svUnit and stack overflow sites)

> (Happy to hear additional points of view on this, my understanding of 
> RUnit and svUnit is limited.)

extensive unit testing lets me experiment broad internal changes.
the xml report of svUnit, combined with jenkins, automates the boring
part of the task. pity we still miss a coverage report.

Mario



[Rd] seeing feedback when R CMD check pkg runs unit tests.
Mario Frasca