[Sciviews-commits] r280 - komodo/SciViews-K Unit komodo/SciViews-K Unit/content/js pkg/svUnit pkg/svUnit/R pkg/svUnit/inst/doc pkg/svUnit/inst/komodo pkg/svUnit/man
noreply at r-forge.r-project.org
noreply at r-forge.r-project.org
Mon May 17 17:16:38 CEST 2010
Author: phgrosjean
Date: 2010-05-17 17:16:37 +0200 (Mon, 17 May 2010)
New Revision: 280
Added:
komodo/SciViews-K Unit/sciviewskunit-0.7.2-ko.xpi
Modified:
komodo/SciViews-K Unit/content/js/sciviewskunit.js
komodo/SciViews-K Unit/install.rdf
pkg/svUnit/DESCRIPTION
pkg/svUnit/NEWS
pkg/svUnit/R/svSuite.R
pkg/svUnit/R/svUnit-internal.R
pkg/svUnit/TODO
pkg/svUnit/inst/doc/svUnit.Rnw
pkg/svUnit/inst/doc/svUnit.lyx
pkg/svUnit/inst/doc/svUnit.pdf
pkg/svUnit/inst/komodo/sciviewskunit-ko.xpi
pkg/svUnit/man/svSuite.Rd
Log:
svUnit 0.7-2:
- Added unitname argument in runTest.svSuite() (thanks to Thomas Wutzler)
- Reworked vignette
- Inactivation of test unit auto mode on startup of Komodo
- Correction in code when svUnit is not installed in R
Modified: komodo/SciViews-K Unit/content/js/sciviewskunit.js
===================================================================
--- komodo/SciViews-K Unit/content/js/sciviewskunit.js 2010-05-16 10:11:23 UTC (rev 279)
+++ komodo/SciViews-K Unit/content/js/sciviewskunit.js 2010-05-17 15:16:37 UTC (rev 280)
@@ -1,6 +1,6 @@
// SciViews-K R unit functions
// Define the 'sv.r.unit' namespace
-// Copyright (c) 2008, Philippe Grosjean
+// Copyright (c) 2008-2010, Philippe Grosjean
////////////////////////////////////////////////////////////////////////////////
// sv.r.unit.version // Version of the svUnit R package it was designed for
@@ -41,8 +41,8 @@
// Define the 'sv.r.unit' namespace
if (typeof(sv.r.unit) == 'undefined') sv.r.unit = {
version: 0.7,
- release: 1,
- debug: true
+ release: 2,
+ debug: false
};
(function() { // 'sv.r.unit' namespace inside closure
@@ -87,8 +87,8 @@
// TODO: a more sophisticated process looking (1) if svUnit R package
// is installed, and (2) if its version is correct. If not, propose to
// install or update it!
- sv.r.evalHidden('require(svUnit, quietly = TRUE)', false); // Make sure svUnit is loaded
- var cmd = 'cat(guiSuiteList(sep = ",", compare = FALSE))';
+ var cmd = 'if (require(svUnit, quietly = TRUE)) ' +
+ 'cat(guiSuiteList(sep = ",", compare = FALSE))';
sv.r.evalCallback(cmd, sv.r.unit.getRUnitList_Callback);
}
@@ -166,8 +166,8 @@
this.setAutoTest = function(state) {
var autoTestButton = document.getElementById('svunit-auto-tests-button');
- if (autoTestButton.checked != state) {
- autoTestButton.checked = state;
+ if (autoTestButton.getAttribute("checked") != state) {
+ autoTestButton.setAttribute("checked", state);
this.autoTest();
}
}
@@ -182,14 +182,15 @@
var autoTestButton = document.getElementById('svunit-auto-tests-button');
var runTestsButton = document.getElementById('svunit-run-tests-button');
//runTestsButton.disabled = autoTestButton.checked;
- if (autoTestButton.checked) {
+ if (autoTestButton.getAttribute("checked") == "true") {
gUnitTestRunning = false; // Reset testing flag TODO: what if test is running?
gFileObserver.addObserver();
this.runTest();
} else {
gFileObserver.removeObserver();
}
- gPrefSvc.prefs.setBooleanPref("svunitAutoTest", autoTestButton.checked);
+ gPrefSvc.prefs.setBooleanPref("svunitAutoTest",
+ autoTestButton.getAttribute("checked"));
} catch (e) {
alert(e);
}
@@ -230,9 +231,9 @@
var progressbar = document.getElementById('svunit-progress-bar');
progressbar.style.backgroundColor = "#E6E6E6";
// Collect together selected tests and run them
- var cmd = 'require(svUnit, quietly = TRUE); createLog(deleteExisting = TRUE); runTest(svSuite(c("'
+ var cmd = 'if (require(svUnit, quietly = TRUE)) { createLog(deleteExisting = TRUE); runTest(svSuite(c("'
cmd = cmd + Selected.join('", "')
- cmd = cmd + '")), name = "objects"); cat(guiTestReport(Log()))'
+ cmd = cmd + '")), name = "objects"); cat(guiTestReport(Log())) }'
// if (this.debug) alert("'" + cmd + "'");
var res = sv.r.evalCallback(cmd, sv.r.unit.runTest_finished);
ko.statusBar.AddMessage("R unit test started", "svUnit", 1000, true);
@@ -694,6 +695,9 @@
this.InitOverlay = function() {
gUnitTreeObject = new _UnitTree();
+ // Make sure "Auto" mode is turned off at startup
+ document.getElementById('svunit-auto-tests-button')
+ .setAttribute("checked", "false");
}
}).apply(sv.r.unit);
Modified: komodo/SciViews-K Unit/install.rdf
===================================================================
--- komodo/SciViews-K Unit/install.rdf 2010-05-16 10:11:23 UTC (rev 279)
+++ komodo/SciViews-K Unit/install.rdf 2010-05-17 15:16:37 UTC (rev 280)
@@ -4,7 +4,7 @@
<Description about="urn:mozilla:install-manifest">
<em:id>sciviewskunit at sciviews.org</em:id>
<em:name>SciViews-K Unit</em:name>
- <em:version>0.7.1</em:version>
+ <em:version>0.7.2</em:version>
<em:description>SciViews-K Unit - Interface to the svUnit R package</em:description>
<em:creator>Philippe Grosjean</em:creator>
<em:homepageURL>http://sciviews.org/SciViews-K</em:homepageURL>
@@ -16,7 +16,7 @@
<!-- Komodo IDE's uuid -->
<em:id>{36E66FA0-F259-11D9-850E-000D935D3368}</em:id>
<em:minVersion>4.1</em:minVersion>
- <em:maxVersion>5.*</em:maxVersion>
+ <em:maxVersion>6.*</em:maxVersion>
</Description>
</em:targetApplication>
<em:targetApplication>
@@ -24,7 +24,7 @@
<!-- Komodo Edit's uuid -->
<em:id>{b1042fb5-9e9c-11db-b107-000d935d3368}</em:id>
<em:minVersion>4.1</em:minVersion>
- <em:maxVersion>5.*</em:maxVersion>
+ <em:maxVersion>6.*</em:maxVersion>
</Description>
</em:targetApplication>
</Description>
Added: komodo/SciViews-K Unit/sciviewskunit-0.7.2-ko.xpi
===================================================================
(Binary files differ)
Property changes on: komodo/SciViews-K Unit/sciviewskunit-0.7.2-ko.xpi
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Modified: pkg/svUnit/DESCRIPTION
===================================================================
--- pkg/svUnit/DESCRIPTION 2010-05-16 10:11:23 UTC (rev 279)
+++ pkg/svUnit/DESCRIPTION 2010-05-17 15:16:37 UTC (rev 280)
@@ -4,8 +4,8 @@
Depends: R (>= 1.9.0)
Suggests: svGUI, datasets, utils
Description: A complete unit test system and functions to implement its GUI part
-Version: 0.6-4
-Date: 2009-10-10
+Version: 0.7-2
+Date: 2010-05-17
Author: Philippe Grosjean
Maintainer: Philippe Grosjean <phgrosjean at sciviews.org>
License: GPL-2
Modified: pkg/svUnit/NEWS
===================================================================
--- pkg/svUnit/NEWS 2010-05-16 10:11:23 UTC (rev 279)
+++ pkg/svUnit/NEWS 2010-05-17 15:16:37 UTC (rev 280)
@@ -1,5 +1,12 @@
= svUnit News
+== svUnit 0.7-2
+
+* Added a unitname argument in runTest.svSuite() to select one test unit
+ to run in the test suite. Thanks to Thomas Wutzler for submitting this
+ patch.
+
+
== svUnit 0.7-1
* Upgrade to the Komodo SciViews-K Unit plugin version 0.7-1.
Modified: pkg/svUnit/R/svSuite.R
===================================================================
--- pkg/svUnit/R/svSuite.R 2010-05-16 10:11:23 UTC (rev 279)
+++ pkg/svUnit/R/svSuite.R 2010-05-17 15:16:37 UTC (rev 280)
@@ -205,7 +205,7 @@
}
"runTest.svSuite" <-
-function (x, name = make.names(deparse(substitute(x))), ...)
+function (x, name = make.names(deparse(substitute(x))), unitname = NULL, ...)
{
# Compile and run the test for this 'svSuite' object
if (!is.svSuite(x))
@@ -254,9 +254,20 @@
for (dir in dirs)
files <- c(files, list.files(dir, pattern = "^runit.+\\.[rR]$",
full.names = TRUE))
- if (length(files) == 0) return(NULL) # Nothing to run!
+ if (length(files) == 0) return(NULL) # Nothing to run!
# Under Windows, transform all \\ into / in the file names
files <- gsub("\\\\", "/", files)
+ # Added by Thomas Wurtzler to control which unit test to run
+ if (!is.null(unitname)) {
+ unitname <- deparse(substitute(unitname))
+ testNames <- gsub("^.*runit(.+)\\.[rR]$", "\\1", files)
+ keep <- which(testNames == unitname)
+ files <- files[keep]
+ if (length(files) == 0) {
+ warning("Test unit ", unitname, " not found")
+ return(NULL)
+ }
+ }
# Run this test suite now, that is, source each file in .TestSuiteEnv
# and run each testxxx function in it, using .setUp and .tearDown too
# Record the list of tests
Modified: pkg/svUnit/R/svUnit-internal.R
===================================================================
--- pkg/svUnit/R/svUnit-internal.R 2010-05-16 10:11:23 UTC (rev 279)
+++ pkg/svUnit/R/svUnit-internal.R 2010-05-17 15:16:37 UTC (rev 280)
@@ -30,7 +30,7 @@
".packageName" <- "svUnit"
-".komodoExtensionMinVersion" <- "0.7.1"
+".komodoExtensionMinVersion" <- "0.7.2"
".installUpgradeKomodoExtension" <-
function ()
Modified: pkg/svUnit/TODO
===================================================================
--- pkg/svUnit/TODO 2010-05-16 10:11:23 UTC (rev 279)
+++ pkg/svUnit/TODO 2010-05-17 15:16:37 UTC (rev 280)
@@ -11,20 +11,10 @@
* RUnit code coverage functions.
-* People ask for checkWarning() function... But warnings are not part of code
- execution. Provide an example to show how, by using options(warning = ...) and
- checkException(), one can detect warnings.
-
-* butler: benchmark and profiling => check it.
-
-* Split example test into smaller test functions.
-
-* Make a vignette (and perhaps a demo) for this package.
-
* Translate this package.
* In RUnit/share/R, there are checkCode.r and compareRUnitTestData.r. The former
- provides functions for test R code in R files, the latter does a comparison of
+ provides functions to test R code in R files, the latter does a comparison of
timings in two test set runs, using a tolerance value. Worth checking and
integrating later on!
Modified: pkg/svUnit/inst/doc/svUnit.Rnw
===================================================================
--- pkg/svUnit/inst/doc/svUnit.Rnw 2010-05-16 10:11:23 UTC (rev 279)
+++ pkg/svUnit/inst/doc/svUnit.Rnw 2010-05-17 15:16:37 UTC (rev 280)
@@ -1,11 +1,16 @@
-%% LyX 1.6.3 created this file. For more info, see http://www.lyx.org/.
+%% LyX 1.6.5 created this file. For more info, see http://www.lyx.org/.
%% Do not edit unless you really know what you are doing.
-\documentclass[a4paper,english]{article}
-\usepackage{lmodern}
+\documentclass[twoside,english]{article}
+\usepackage{mathpazo}
\renewcommand{\sfdefault}{lmss}
\renewcommand{\ttdefault}{lmtt}
\usepackage[T1]{fontenc}
\usepackage[latin9]{inputenc}
+\usepackage{listings}
+\usepackage[a4paper]{geometry}
+\geometry{verbose,tmargin=3cm,bmargin=4.5cm,lmargin=2.5cm,rmargin=3cm}
+\usepackage{fancyhdr}
+\pagestyle{fancy}
\usepackage{color}
\usepackage{babel}
@@ -13,16 +18,20 @@
\usepackage{url}
\usepackage{graphicx}
\definecolor{shadecolor}{rgb}{0.7,0.7,0.7}
-\usepackage[unicode=true, pdfusetitle,
+\usepackage[unicode=true,
bookmarks=true,bookmarksnumbered=false,bookmarksopen=false,
breaklinks=true,pdfborder={0 0 1},backref=false,colorlinks=true]
{hyperref}
-
+\hypersetup{pdftitle={svUnit - A framework for unit testing in R},
+ pdfauthor={Philippe Grosjean},
+ pdfsubject={Test units using the svUnit R package},
+ pdfkeywords={test unit, extreme programming, code refactoring, quality insurance}}
+
\makeatletter
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% LyX specific LaTeX commands.
-\providecommand{\proglang}[1]{\textsf{#1}}
+\providecommand{\R}{\textsf{R}}
\providecommand{\file}[1]{`\textsf{#1}'}
@@ -34,11 +43,12 @@
\providecommand{\var}[1]{{\normalfont\textsl{#1}}}
-\providecommand{\kbd}[1]{\textsf{\textsc{#1}}}
+\providecommand{\SciViews}[1]{\textsf{Sc\lower.08em\hbox{i}\kern-.03emV\kern-.03em\lower.08em\hbox{i}ews\@#1}}
+\providecommand{\menuitem}[1]{\textsf{\textsc{#1}}}
+
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Textclass specific LaTeX commands.
-\newenvironment{lyxSchunk}{}{}
\newenvironment{lyxlist}[1]
{\begin{list}{}
{\settowidth{\labelwidth}{#1}
@@ -59,6 +69,7 @@
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% User specified LaTeX commands.
% \VignetteIndexEntry{svUnit - A framework for unit testing in R}
+%\VignettePackage{svUnit}
\makeatother
@@ -67,7 +78,7 @@
\title{svUnit - A framework for unit testing in R }
-\date{Version 0.6-2, 2009-01-12}
+\date{Version 0.7-2, 2010-05-17}
\author{Philippe Grosjean (phgrosjean at sciviews.org)}
@@ -82,10 +93,10 @@
that the software is doing the right calculation (quality insurance).
Basically, a test just checks if the code is running and is producing
the correct answer/behavior in a given situation. As such, unit tests
-are build in \proglang{R} package production because all examples
-in documentation files, and perhaps, test code in \file{/tests} subdirectory
-are run during the checking of a package (\command{R CMD check <Pkg>}).
-However, the \proglang{R} approach lacks a certain number of features
+are build in \R{} package production because all examples in documentation
+files, and perhaps, test code in \file{/tests} subdirectory are run
+during the checking of a package (\command{\inputencoding{latin1}R CMD check <pkg>\selectlanguage{english}
+}). However, the \R{} approach lacks a certain number of features
to allow optimal use of unit tests as in extreme programming (test
first \textendash{} code second):
\begin{itemize}
@@ -94,13 +105,13 @@
\item Once a test fails, the checking process is interrupted. Thus one has
to correct the bug and launch package checking again... and perhaps
get caught by the next bug. It is a long and painful process.
-\item There is no way to select one or several tests: all are run or not
-(depending on command line options) during package testing.
-\item It is impossible to program in \proglang{R} in a test driven development
-(\url{http://en.wikipedia.org/wiki/Test- driven_development}, write
-tests first).
-\item Consequently, the {}`test-code-simplify' cycle is not accessible
-yet to \proglang{R} programmer, because of the lack of an interactive
+\item There is no way to choose one or several tests selectively: all are
+run or not (depending on command line options) during package testing.
+\item It is very hard, or near to impossible to program in \R{} in a test
+driven development (\emph{write tests first}) with the standard tools
+(\url{http://en.wikipedia.org/wiki/Test- driven_development}).
+\item Consequently, the {}`\emph{test-code-simplify}' cycle is not easily
+accessible yet to \R{} programmer, because of the lack of an interactive
and flexible testing mechanism providing immediate, or quasi immediate
feedback about changes made.
\item We would like also to emphasize that test suites are not only useful
@@ -111,380 +122,367 @@
\subsection{Unit testing in R without svUnit}
Besides the \textquotedbl{}regular\textquotedbl{} testing mechanism
-of \proglang{R} packages, one can find the \pkg{RUnit} package on
-CRAN (\url{http://cran.r-project.org}). Another package used to provide
-test unit, \pkg{butler}, but it is not maintained any more and seems
-to have given up in favor of \pkg{RUnit}. \pkg{RUnit} implements
-the following features:
+of \R{} packages, one can find the \pkg{RUnit} package on CRAN (\url{http://cran.r-project.org}).
+Another package used to provide an alternate implementation of test
+unit: \pkg{butler} , but it is not maintained any more and has given
+up in favor of \pkg{RUnit}. \pkg{RUnit} implements the following
+features:
\begin{itemize}
-\item \textbf{Assertions} for tests (\code{checkEquals()}, \code{checkEqualsNumeric()},
-\code{checkIdentical()} and \code{checkTrue()}) and negative tests
-(tests that check error conditions, \code{checkException()}).
-\item Assertions are grouped into \proglang{R} functions to form one \textbf{test
-function}. It is easy to temporarily inactivate one or more tests
-by commenting lines in the function. To avoid forgetting tests that
-are commented out later on, there is special function, named \code{DEACTIVATED()},
-that tags the test with a reminder for your deactivated items (i.e.,
-this is written in the test protocol).
-\item A series of test functions (whose name typically start with \code{test}...)
-are collected together in a sourceable \proglang{R} code file (name
-starting with \code{runit}...) on disk. This file is called a \textbf{test
-unit}.
+\item \textbf{Assertions,} \code{\inputencoding{latin1}checkEquals()\selectlanguage{english}
+}, \code{\inputencoding{latin1}checkEqualsNumeric()\selectlanguage{english}
+}, \code{\inputencoding{latin1}checkIdentical()\selectlanguage{english}
+} and \code{\inputencoding{latin1}checkTrue()\selectlanguage{english}
+} and negative tests (tests that check error conditions, \code{\inputencoding{latin1}checkException()\selectlanguage{english}
+}).
+\item Assertions are grouped into \R{} functions to form one \textbf{test
+function} that runs a series of related individual tests. It is easy
+to temporarily inactivate one or more tests by commenting lines in
+the function. To avoid forgetting tests that are commented out later
+on, there is special function, named \code{\inputencoding{latin1}DEACTIVATED()\selectlanguage{english}
+} that tags the test with a reminder for your deactivated items (i.e.,
+the reminder is written in the test log).
+\item A series of test functions (whose name typically start with \code{\inputencoding{latin1}test....\selectlanguage{english}
+}) are collected together in a sourceable \R{} code file (name starting
+with \code{\inputencoding{latin1}runit....\selectlanguage{english}
+} ) on disk. This file is called a \textbf{test unit}.
\item A \textbf{test suite} (object \var{RUnitTestSuite}) is a special
-object defining a battery of tests to run. It points to one or several
-directories containing test units. A test suite is defined by \code{defineTestSuite()}.
-\item One or more test suites can be run by calling \code{runTestSuite()}.
-There is a convenient shortcut to define and run a test suite constituted
-by only one test unit by using the function \code{runTestFile()}.
-Once the test is run, a \var{RUnitTestData} object is created that
+object defining a battery of tests It points to one or several directories
+containing test units. A test suite is defined by \code{\inputencoding{latin1}defineTestSuite()\selectlanguage{english}
+}.
+\item One or more test suites can be run by calling \code{\inputencoding{latin1}runTestSuite()\selectlanguage{english}
+}. There is a shortcut to define and run a test suite constituted by
+only one test unit by using the function \code{\inputencoding{latin1}runTestFile()\selectlanguage{english}
+}. Once the test is run, a \var{RUnitTestData} object is created that
contains all the information collected from the various tests run.
\item One can print a synthetic report (how many test units, test functions,
number of errors, fails and deactivated item), or get a more extensive
-\code{summary()} of the test with indication about the tests that
-failed. The function \code{printTextProtocol()} does the same, while
-\code{printHTMLProtocol()} produces a report in HTML format.
+\code{\inputencoding{latin1}summary()\selectlanguage{english}
+} of the tests with indication about which ones failed or produced
+errors. The function \code{\inputencoding{latin1}printTextProtocol()\selectlanguage{english}
+} does the same, while \code{printHTMLProtocol()} produces a report
+in HTML format.
\item \pkg{RUnit} contains also functions to determine which code is run
in the original function when tested, in order to detect the parts
-of the code not covered by the test suite (code coverage functions
-\code{inspect()} and \code{tracker()}).
+of the code not covered by the test suite (code coverage function
+\code{\inputencoding{latin1}inspect()\selectlanguage{english}
+} and function \code{tracker()}).
\end{itemize}
As complete and nice as \pkg{RUnit} is, there is no tools to integrate
the test suite in a given development environment (IDE) or graphical
user interface (GUI). In particular, there is no real-time reporting
-mechanism used to easy the test-code-simplify cycle. The way tests
-are implemented and run is left to the user, but the implementation
+mechanism used to easy the \emph{test-code-simplify} cycle. The way
+tests are implemented and run is left to the user, but the implementation
suggests that the authors of \pkg{RUnit} mainly target batch execution
of the tests (for instance, nightly check of code in a server), rather
that real-time interaction with the tests.
There is also no integration with the \textquotedbl{}regular\textquotedbl{}
-\command{R CMD check} mechanism of \proglang{R} in \pkg{RUnit}.
-There is an embryo of organization of these tests units to make them
-compatible with the \command{R CMD check} mechanism of \proglang{R}
-on the R Wiki (\url{http://wiki.r-project.org/rwiki/doku.php?id=developers:runit}).
+\command{\inputencoding{latin1}R CMD check\selectlanguage{english}
+} mechanism of \R{} in \pkg{RUnit}. There is an embryo of organization
+of these tests units to make them compatible with \command{\inputencoding{latin1}R CMD check\selectlanguage{english}
+} on the R Wiki (\url{http://wiki.r-project.org/rwiki/doku.php?id=developers:runit}).
This approach works well only on Linux/Unix systems, but needs to
be adapted for Windows.
\subsection{Unit testing framework for R with svUnit}
-Our initial goal, in the context of the EU project UNCOVER, was to
-implement a GUI layer on top of \pkg{RUnit}, and to integrate test
-units as smoothly as possible in a code editor, as well as, making
-tests easily accessible and fully compatible with \command{R CMD check}
-on all platforms supported by \proglang{R}. Ultimately, the test
-suite should be easy to create, to use interactively, and should be
-able to test functions in a complex set of \proglang{R} packages.
+Our initial goal was to implement a GUI layer on top of \pkg{RUnit},
+and to integrate test units as smoothly as possible in a code editor,
+as well as, making tests easily accessible and fully compatible with
+\command{\inputencoding{latin1}R CMD check\selectlanguage{english}
+} on all platforms supported by \R{}. Ultimately, the test suite should
+be easy to create, to use interactively, and should be able to test
+functions in a complex set of \R{} packages.
However, we encountered several difficulties while trying to enhance
\pkg{RUnit} mechanism. When we started to work on this project, \pkg{RUnit}
(version 0.4-17) did not allow to subclass its objects. Moreover,
its \var{RUnitTestData} object is optimized for quick testing, but
not at all for easy reviewing of its content: it is a list of lists
-of lists,... requiring embedded for loop and \code{lapply()}/\code{sapply()}
-procedures to extract its content. Finally, the concept of test units
+of lists,... requiring embedded for loop and \code{\inputencoding{latin1}lapply()\selectlanguage{english}
+} /\code{\inputencoding{latin1}sapply()\selectlanguage{english}
+} procedures to extract its content. Finally, the concept of test units
as sourceable files on disk is a nice idea, but it is too rigid for
-quick writing of test cases for objects not associated (yet) with
-\proglang{R} packages.
+quick writing test cases for objects not associated (yet) with an
+\R{} packages.
We did a first implementation of the \pkg{RUnit} GUI based on these
objects, before realizing that it is really not designed for such
an use. So, we decide to write a completely different unit testing
-framework in \proglang{R}: \pkg{svUnit}, but we make it test code
-compatible with \pkg{RUnit} (i.e., the engine and objects used are
-totally different, but the test code run in \pkg{RUnit} or \pkg{svUnit}
-can be interchangeable).
+framework in \R{} : \pkg{svUnit}, but we make it test code compatible
+with \pkg{RUnit} (i.e., the engine and objects used are totally different,
+but the test code run in \pkg{RUnit} or \pkg{svUnit} is interchangeable).
-Finally, \pkg{svUnit} is also designed to be integrated in the SciViews
-R GUI (\url{http://www.sciviews.org/SciViews-K}), on top of Komodo
+Finally, \pkg{svUnit} is also designed to be integrated in the \SciViews{}
+GUI (\url{http://www.sciviews.org/SciViews-K}), on top of Komodo
Edit (\url{http://www.activestate.com/komodo_edit}), and to approach
extreme programming practices with automatic code testing while you
write it. A rather simple interface is provided to link and pilot
\pkg{svUnit} from any GUI/IDE, and the Komodo Edit implementation
-could be use as example to program similar integration panels for
-other R GUIs. \pkg{svUnit} also formats its report with creole wiki
-syntax. It is directly readable, but it can also be displayed in a
-much nicer way using any wiki engine compatible with the creole wiki
-language. It is thus rather easy to write test reports in wiki servers,
-possibly through nightly automatic process for your code, if you like.
+could be used as an example to program similar integration panels
+for other \R{} GUIs. \pkg{svUnit} also formats its report with \emph{creole
+wiki} syntax. It is directly readable, but it can also be displayed
+in a much nicer way using any wiki engine compatible with the creole
+wiki language. It is thus rather easy to write test reports in wiki
+servers, possibly through nightly automatic process for your code,
+if you like.
-This vignette is a guided tour of svUnit, showing you its features
-and the various ways you can use it to test your \proglang{R} code.
+This vignette is a guided tour of \pkg{svUnit}, showing its features
+and the various ways you can use it to test your \R{} code.
\section{Installation}
-The \pkg{svUnit} package is not available on CRAN (\url{http://cran.r-project.org})
-yet, but it is available from R-Forge (\url{http://r-forge.r-project.org}).
-You can download it from \proglang{R} by:
-\begin{lyxSchunk}
-<<eval = FALSE>>=
+The \pkg{svUnit} package is available on CRAN (\url{http://cran.r-project.org}),
+and its latest development version is also available on R-Forge (\url{http://sciviews.r-forge.r-project.org/}).
+You can install it with%
+\footnote{Install the development version with \code{install.packages(\textquotedbl{}svUnit\textquotedbl{}, repos = \textquotedbl{}http://r-forge.r-project.org\textquotedbl{})}.%
+}:
-install.packages("svUnit",repos="http://R-Forge.R-project.org")
-@
-\end{lyxSchunk}
+\SweaveOpts{keep.source = TRUE}
-\begin{lyxSchunk}
-<<echo = FALSE, results = hide>>=
+<<echo = FALSE, results = hide>>=
options(useFancyQuotes = FALSE)
+@
+
+<<eval = FALSE>>=
+install.packages("svUnit")
@
-\end{lyxSchunk}
-This package has no dependence other than R $\geq$ 1.9.0. However,
+This package has no dependence other than \R{} $\geq$ 1.9.0. However,
if you would like to use its interactive mode in a GUI editor, you
-must also install Komodo Edit and SciViews. The procedure is explaned
-at \url{http://www.sciviews.org/SciViews-K}.
+must also install Komodo Edit and \SciViews{}-K. The procedure is
+explaned at \url{http://www.sciviews.org/SciViews-K}.
-Once the svUnit package is installed, you can check it is working
-well with the following example code:
-\begin{lyxSchunk}
-<<>>=
+Once the \pkg{svUnit} package is installed, you can check it is working
+correctly on your machine with the following example code:
-library(svUnit)
-Square <- function(x) return(x^2)
-
-test(Square) <- function() {
-
- checkEquals(9, Square(3))
-
- checkEquals(10, Square(3)) # This intentionally fails
-
- checkEquals(9, SSSquare(3)) # This intentionally raises error
-
- checkEquals(c(1, 4, 9), Square(1:3))
-
+<<>>=
+library(svUnit)
+Square <- function (x) return(x^2)
+test(Square) <- function () {
+ checkEqualsNumeric(9, Square(3))
+ checkEqualsNumeric(10, Square(3)) # This intentionally fails
+ checkEqualsNumeric(9, SSSquare(3)) # This raises error
+ checkEqualsNumeric(c(1, 4, 9), Square(1:3))
checkException(Square("xx"))
-
}
-
clearLog()
-
(runTest(Square))
-
@
-\end{lyxSchunk}
+
%
\begin{framed}%
Although test unit code is compatible with both \pkg{svUnit} and
-\pkg{RUnit}, do not load both packages in \proglang{R} memory at
-the same time, or you will badly mix incompatible code between them!\end{framed}
+\pkg{RUnit}, do not load both packages in \R{} memory at the same
+time, or you will badly mix incompatible code!\end{framed}
\section{Overview of svUnit}
-You ensure that code you write in \proglang{R} functions does work
-as you want by defining a battery of tests that will compare the output
-of your code with reference values. In \pkg{svUnit}, the simplest
-way to define such a battery of tests is by attaching it to functions
-loaded in \proglang{R} memory%
-\footnote{In fact, you can attach \pkg{svUnit} tests to any kind of \proglang{R}
-object, not only function. This could be useful to test S3/S4 objects,
-or even, datasets. %
+You ensure that code you write in your \R{} functions does the expected
+work by defining a battery of tests that will compare the output of
+your code with reference values. In \pkg{svUnit}, the simplest way
+to define such a battery of tests is by attaching it to functions
+loaded in \R{} memory%
+\footnote{In fact, you can attach \pkg{svUnit} tests to any kind of \R{} object,
+not only function. This could be useful to test S3/S4 objects, or
+even, datasets. %
}. Of course, you can also define batteries of tests that are independent
-of any \proglang{R} object, or that check several of them together
-(integration tests). Here is a couple of examples:
-\begin{lyxSchunk}
-<<>>=
+of any \R{} object, or that check several of them together (so called,
+\emph{integration tests}). Here is a couple of examples:
-library(svUnit)
-# Create two R functions that include their test own cases
-
-Square <- function(x) return(x^2)
-
-test(Square) <- function() {
-
- checkEquals(9, Square(3))
-
- checkEquals(c(1, 4, 9), Square(1:3))
-
+<<>>=
+library(svUnit)
+# Create two R functions that include their own test cases
+Square <- function (x) return(x^2)
+test(Square) <- function () {
+ checkEqualsNumeric(9, Square(3))
+ checkEqualsNumeric(c(4, 9), Square(2:3))
checkException(Square("xx"))
-
}
-
-
-Cube <- function(x) return(x^3)
-
-test(Cube) <- function() {
-
- checkEquals(27, Cube(3))
-
- checkEquals(c(1, 8, 28), Cube(1:3))
-
+Cube <- function (x) return(x^3)
+test(Cube) <- function () {
+ checkEqualsNumeric(27, Cube(3))
+ checkEqualsNumeric(c(8, 28), Cube(2:3))
checkException(Cube("xx"))
-
}
-
-
-# Add a separate test case object (not attached to a particular object)
-
-test_Integrate <- svTest(function() {
-
+# Add a separate test case
+test_Integrate <- svTest(function () {
checkTrue(1 < 2, "check1")
-
- v <- 1:3 # The reference
-
- w <- 1:3 # The value to compare to the reference
-
+ v <- c(1, 2, 3) # The reference
+ w <- 1:3 # The value to compare to the reference
checkEquals(v, w)
-
-})
-
+})
@
-\end{lyxSchunk}
+
When you run a test in \pkg{svUnit}, it logs its results in a centralized
logger. The idea is to get a central repository for tests that you
can manipulate as you like (print, summarize, convert, search, display
in a GUI, etc.). If you want to start new tests, you should first
-clean this logger by \code{cleanLog()}. At any time, the logger is
-accessible by \code{Log()}, and a summary of its containt is displayed
-using \code{summary(Log())}. So, to run test for your \code{Square()}
-function as well as your \code{test\_Integrate} integration test,
+clean this logger by \code{\inputencoding{latin1}clearLog()\selectlanguage{english}
+}. At any time, the logger is accessible by \code{\inputencoding{latin1}Log()\selectlanguage{english}
+}, and a summary of its containt is displayed using \code{\inputencoding{latin1}summary(Log())\selectlanguage{english}
+}. So, to run test for your \code{\inputencoding{latin1}Square()\selectlanguage{english}
+} function as well as your \var{test\_Integrate} integration test,
you simply do the following:
-\begin{lyxSchunk}
-<<>>=
-clearLog()
+<<>>=
+clearLog()
runTest(Square)
-
runTest(test_Integrate)
-
Log()
-
@
-\end{lyxSchunk}
-From this report, you see that all your tests succeed. Note that \pkg{svUnit}
+
+In this report, you see that all your tests succeed. Note that \pkg{svUnit}
is making the difference between a test that \textbf{fails} (the code
-is run correctly, but the result is different that what was expected)
-and code that raises \textbf{error} (it was not possible to run the
-test because its code is incorrect, or for some other reasons). Note
-also that the function \code{checkException()} is designed to explicitly
-test code that should stop() in R. So, if that test does not raises
-an exception, it is considered to have failed. This is useful to check
-that your functions correctly trap wrong arguments, for instance,
-like in \code{checkException(Square(\textquotedbl{}xx\textquotedbl{}))}
-here above (a character string is provided where a numerical value
+is run correctly, but the result is different what was expected) and
+code that raises \textbf{error} (it was not possible to run the test
+because its code is incorrect, or for some other reasons). Note also
+that the function \code{\inputencoding{latin1}checkException()\selectlanguage{english}
+} is designed to explicitly test code that should \code{stop()} in
+\R{}%
+\footnote{\code{\inputencoding{latin1}checkException()\selectlanguage{english}
+} can also track \code{\inputencoding{latin1}warning()\selectlanguage{english}
+} messages with this little trick: first convert all warnings into
+errors with \code{\inputencoding{latin1}owarn <- options(warn = 2)\$warn\selectlanguage{english}
[TRUNCATED]
To get the complete diff run:
svnlook diff /svnroot/sciviews -r 280
More information about the Sciviews-commits
mailing list