From pgilbert902 at gmail.com  Wed Sep 10 15:46:27 2014
From: pgilbert902 at gmail.com (Paul Gilbert)
Date: Wed, 10 Sep 2014 09:46:27 -0400
Subject: [Rd] How to test impact of candidate changes to package?
In-Reply-To: <54102412.3080404@ivt.baug.ethz.ch>
References: <526d73b585084eecb2b72a92ab9f74b0@DB3PR01MB252.eurprd01.prod.exchangelabs.com>	<AA818EAD2576BC488B4F623941DA7427F3AEA7E5@inbomail.inbo.be>	<e476aba80ced41e0b8ed9ec181cd423f@DB3PR01MB252.eurprd01.prod.exchangelabs.com>
	<54102412.3080404@ivt.baug.ethz.ch>
Message-ID: <54105633.1070000@gmail.com>



On 09/10/2014 06:12 AM, Kirill M?ller wrote:
> If you don't intend to keep the old business logic in the long run,
> perhaps a version control system such as Git can help you. If you use it
> in single-user mode, you can think of it as a backup system where you
> manually create each snapshot and give it a name, but it actually can do
> much more. For your use case, you can open a new *branch* where you
> implement your changes, and implement your testing logic simultaneously
> in both branches (using *merge* operations). The system handles
> switching between branches, so you can really perform invasive changes,
> and revert if you find that a particular change breaks something.
>...

Yes, I would strongly recommend some version control system for this, 
probably either Git or svn (Subversion). If this is all code and test 
data that you can release publicly then you might choose some public 
repository like Github or R-forge. (You will get lots of opinions about 
the relative merits of different repositories if you ask, but the main 
point is that any one of them will be better than nothing.) If part of 
your code and data cannot be released then you might check if something 
is already supported in your place of business. Chances are that it is, 
but only programmers in IT have been told about it.

On 09/10/2014 11:14 AM, Stephanie Locke wrote:
 >> ...
>> Has anyone else had to do this sort of testing before on their
>> packages? How did you do it? Am I missing an obvious package /
>> framework that can do this?

Most package maintainers would face some version of this problem, some 
simpler and some much more complicated. If you set up the tests as 
scripts in the package tests/ directory that issue stop() in the case of 
a problem, then R-forge pretty much does the checking for you on 
multiple platforms, at least when it is working properly.

It is probably more trouble than it is worth for a single package, but 
if you have several packages with inter-dependencies then you might want 
to look at the develMake framework at 
http://automater.r-forge.r-project.org/

Regards,
Paul
>>
>> Cheers,
>> Steph
>>
>> --
>> Stephanie Locke
>> BI & Credit Risk Analyst



[Rd] How to test impact of candidate changes to package?
Paul Gilbert