[Sciviews-commits] r287 - in pkg/svUnit: . R inst/doc inst/komodo man
noreply at r-forge.r-project.org
noreply at r-forge.r-project.org
Sun Sep 5 18:10:46 CEST 2010
Author: phgrosjean
Date: 2010-09-05 18:10:46 +0200 (Sun, 05 Sep 2010)
New Revision: 287
Added:
pkg/svUnit/man/unitTests.svUnit.Rd
Removed:
pkg/svUnit/man/unitTests.Rd
Modified:
pkg/svUnit/DESCRIPTION
pkg/svUnit/NEWS
pkg/svUnit/R/Log.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/check.Rd
pkg/svUnit/man/svSuite.Rd
pkg/svUnit/man/svSuiteData.Rd
pkg/svUnit/man/svTestData.Rd
pkg/svUnit/man/svUnit-package.Rd
Log:
Slight reworking of the example(unitTests.<mypackage>) and R CMD check mechanism for unit tests
Modified: pkg/svUnit/DESCRIPTION
===================================================================
--- pkg/svUnit/DESCRIPTION 2010-09-05 16:09:00 UTC (rev 286)
+++ pkg/svUnit/DESCRIPTION 2010-09-05 16:10:46 UTC (rev 287)
@@ -5,7 +5,7 @@
Suggests: svGUI, datasets, utils
Description: A complete unit test system and functions to implement its GUI part
Version: 0.7-3
-Date: 2010-09-03
+Date: 2010-09-05
Author: Philippe Grosjean
Maintainer: Philippe Grosjean <phgrosjean at sciviews.org>
License: GPL-2
Modified: pkg/svUnit/NEWS
===================================================================
--- pkg/svUnit/NEWS 2010-09-05 16:09:00 UTC (rev 286)
+++ pkg/svUnit/NEWS 2010-09-05 16:10:46 UTC (rev 287)
@@ -4,6 +4,18 @@
* Loading of svUnit sometimes failed during checking of the SciViews-K Unit
plugin installation in Komodo Edit/IDE. Corrected. Thanks Claudia Beleites.
+
+* The unitTest.svUnit man page now uses require(svUnit) in a mechanism that
+ ignores the tests in case svUnit is not installed in a machine where R CMD
+ check is run.
+
+* errorLog() now briefly reports statistics on all test run when used in
+ interactive() mode. This is more appropriate when the tests are run by using
+ example(unitTests.<mypackage>), while it does not change original behaviour
+ (silent execution of the tests, except in case of failure or error) during
+ the R CMD check process.
+
+* The package vignette is updated to reflect these changes.
== svUnit 0.7-2
Modified: pkg/svUnit/R/Log.R
===================================================================
--- pkg/svUnit/R/Log.R 2010-09-05 16:09:00 UTC (rev 286)
+++ pkg/svUnit/R/Log.R 2010-09-05 16:10:46 UTC (rev 287)
@@ -54,6 +54,9 @@
if (isTRUE(summarize)) summary(.Log)
msg <- paste(Res[2], "failure(s) and", Res[3], "error(s)")
stop(msg)
+ } else if (interactive()) {
+ cat("Summary statistics on all tests run:\n")
+ print(Res)
}
return(invisible(Res))
}
Modified: pkg/svUnit/R/svUnit-internal.R
===================================================================
--- pkg/svUnit/R/svUnit-internal.R 2010-09-05 16:09:00 UTC (rev 286)
+++ pkg/svUnit/R/svUnit-internal.R 2010-09-05 16:10:46 UTC (rev 287)
@@ -28,7 +28,7 @@
.packageName <- "svUnit"
-.komodoExtensionMinVersion <- "0.9.0"
+.komodoExtensionMinVersion <- "0.7.3"
.installUpgradeKomodoExtension <- function ()
{
Modified: pkg/svUnit/TODO
===================================================================
--- pkg/svUnit/TODO 2010-09-05 16:09:00 UTC (rev 286)
+++ pkg/svUnit/TODO 2010-09-05 16:10:46 UTC (rev 287)
@@ -2,8 +2,6 @@
* guiTestFeedback() must be finished.
-* Install SciViews-K Unit Komodo extension.
-
* Output results in html, latex, wiki, etc. format (summary.svSuiteData).
* Queue tests to run and run them asynchronously using tcltk and after() if
Modified: pkg/svUnit/inst/doc/svUnit.Rnw
===================================================================
--- pkg/svUnit/inst/doc/svUnit.Rnw 2010-09-05 16:09:00 UTC (rev 286)
+++ pkg/svUnit/inst/doc/svUnit.Rnw 2010-09-05 16:10:46 UTC (rev 287)
@@ -35,20 +35,28 @@
\providecommand{\file}[1]{`\textsf{#1}'}
-\providecommand{\command}[1]{\texttt{#1}}
+\providecommand{\command}{\bgroup\@noligs\@cmdx}
+\def\@cmdx#1{{\normalfont\texttt{#1}}\egroup}
\providecommand{\pkg}[1]{{\fontseries{b}\selectfont #1}}
-\providecommand{\code}[1]{\texttt{#1}}
+{\catcode`\ =\active\global\def\code{\bgroup\@noligs\catcode`\ =\active\let \codespace\@codex}}
+\def\codespace{{ }}
+\def\@codex#1{\normalfont\texttt{#1}\egroup}
\providecommand{\var}[1]{{\normalfont\textsl{#1}}}
-\providecommand{\SciViews}[1]{\textsf{Sc\lower.08em\hbox{i}\kern-.03emV\kern-.03em\lower.08em\hbox{i}ews\@#1}}
+\providecommand{\SciViews}[1]{\textsf{\textsl{S}\lower.08em\hbox{ci}\textsl{\kern-.04emV}\kern-.02em\lower.08em\hbox{iews}\@#1}}
\providecommand{\menuitem}[1]{\textsf{\textsc{#1}}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Textclass specific LaTeX commands.
+\providecommand{\Prob}{\mathop{\mathrm{P}}}
+\providecommand{\E}{\mathop{\mathrm{E}}}
+\providecommand{\VAR}{\mathop{\mathrm{var}}}
+\providecommand{\COV}{\mathop{\mathrm{cov}}}
+\providecommand{\COR}{\mathop{\mathrm{cor}}}
\newenvironment{lyxlist}[1]
{\begin{list}{}
{\settowidth{\labelwidth}{#1}
@@ -78,7 +86,7 @@
\title{svUnit - A framework for unit testing in R }
-\date{Version 0.7-2, 2010-05-17}
+\date{Version 0.7-3, 2010-09-05}
\author{Philippe Grosjean (phgrosjean at sciviews.org)}
@@ -105,7 +113,7 @@
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 choose one or several tests selectively: all are
-run or not (depending on command line options) during package testing.
+run or not (depending on command line options) during package checking.
\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}).
@@ -162,12 +170,12 @@
\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 \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.
+user interface (GUI), as far as we know. In particular, there is no
+real-time reporting 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 \R{} in \pkg{RUnit}. There is
@@ -192,7 +200,7 @@
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
+procedures to extract some content. Finally, the concept of test units
as sourceable files on disk is a nice idea, but it is too rigid for
quick writing test cases for objects not associated (yet) with an
\R{} packages.
@@ -206,17 +214,17 @@
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 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.
+Edit or IDE (\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/IDE
+implementation 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 \pkg{svUnit}, showing its features
and the various ways you can use it to test your \R{} code.
@@ -245,8 +253,8 @@
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{}-K. The procedure is
-explaned at \url{http://www.sciviews.org/SciViews-K}.
+must also install Komodo Edit or Komodo IDE and \SciViews{}-K. The
+procedure is explaned here: \url{http://www.sciviews.org/SciViews-K}.
Once the \pkg{svUnit} package is installed, you can check it is working
correctly on your machine with the following example code:
@@ -257,8 +265,8 @@
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(10, Square(3)) # This intentionally fails
+ checkEqualsNumeric(9, SSSquare(3)) # This raises error
checkEqualsNumeric(c(1, 4, 9), Square(1:3))
checkException(Square("xx"))
}
@@ -290,7 +298,7 @@
<<>>=
library(svUnit)
-# Create two R functions that include their own test cases
+## Create two R functions that include their own test cases
Square <- function (x) return(x^2)
test(Square) <- function () {
checkEqualsNumeric(9, Square(3))
@@ -305,11 +313,11 @@
checkException(Cube("xx"))
}
-# Add a separate test case
+## Add a separate test case
test_Integrate <- svTest(function () {
checkTrue(1 < 2, "check1")
- v <- c(1, 2, 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)
})
@
@@ -333,11 +341,11 @@
@
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 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
+is making the distinction between a test that \textbf{fails} (the
+code is run correctly, but the result is different from 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 \code{stop()} in \R{}%
\footnote{\code{checkException()} can also track \code{warning()} messages
with this little trick: first convert all warnings into errors with
@@ -366,8 +374,8 @@
results are printed. We expected \code{c(8, 28)} (made intentionally
wrong for the sake of the demonstration) from \code{Cube(2:3)} in
\code{checkEqualsNumeric(c(8, 28), Cube(2:3))}, and (of course),
-we got \code{c(8, 27)}. This (misspecified) test shows how \pkg{svUnit}
-presents test failures.
+we got \code{c(8, 27)}. This test shows how \pkg{svUnit} presents
+test failures.
\item The results of the tests on \code{Cube()} are added to the previous
report. So, it is possible to build rather easily reports that summarize
tests on several objects, by adding test results in the logger sequentially.
@@ -487,19 +495,19 @@
<<>>=
-# Clear test exclusion list for running all test suites
+## Clear test exclusion list for running all test suites
options(svUnit.excludeList = NULL)
-# Clear the logger
+## Clear the logger
clearLog()
-# Run all currently defined tests
+## Run all currently defined tests
runTest(svSuiteList(), name = "AllTests")
-# Get some statistics
+## Get some statistics
stats(Log())[, 1:3]
-# A slightly different presentation than with print
+## A slightly different presentation than with print
summary(Log())
-# Metadata collected on the machine where tests are run
+## Metadata collected on the machine where tests are run
metadata(Log())
-# List content of the log
+## List content of the log
ls(Log())
@
@@ -557,7 +565,7 @@
w <- 1:3 # The object to compare to the reference
checkEqualsNumeric(v, w)
}
-# Turn this function into a test
+## Turn this function into a test
test_function <- as.svTest(test_function)
is.svTest(test_function)
@
@@ -565,12 +573,12 @@
A test function should be made a special object called \var{svTest},
so that \pkg{svUnit} can recognize it. This \var{svTest} object,
is allowed to live on its own (for instance, in the user's workspace,
-or anywhere you like. It can be defined in a \R{} script, be saved
+or anywhere you like). It can be defined in a \R{} script, be saved
in a \file{.RData} file, etc... Note that this is very different
-from \pkg{RUnit} where test must always be located in a unit test).
-In \pkg{svUnit} (not \pkg{RUnit}), you run such a test simply by
-using \code{runTest()}, which returns the results invisibly and add
-it to the logger:
+from \pkg{RUnit} where test must always be located in a unit test
+file on disk). In \pkg{svUnit} (not \pkg{RUnit}), you run such a
+test simply by using \code{runTest()}, which returns the results
+invisibly and add it to the logger:
<<>>=
@@ -588,10 +596,10 @@
<<>>=
-# A very simple function
+## A very simple function
Square <- function (x) return(x^2)
-# A test case to associate with the Square() function
+## A test case to associate with the Square() function
test(Square) <- function () {
checkEqualsNumeric(9, Square(3))
checkEqualsNumeric(c(1, 4, 9), Square(1:3))
@@ -635,7 +643,7 @@
and should integrate in the already existing testing features of \R{},
in particular, \command{R CMD check}. In both \pkg{RUnit}, and \pkg{svUnit},
one can define such test units, and they are made code compatible
-between the two implementations (at least for version 0.4-17 of \pkg{RUnit}).
+between the two implementations.
A test unit is a sourceable text file that contains one or more test
functions, plus possibly \code{.setUp()} and \code{.tearDown()}
@@ -648,7 +656,7 @@
to a simple test unit containing only one test function:
-<<>>=
+<<eval = FALSE>>=
# Create a test unit on disk and view its content
unit <- makeUnit(Square)
file.show(unit, delete.file = TRUE)
@@ -661,8 +669,8 @@
record of this test unit file. Note also that \code{.setUp()} and
\code{.tearDown()} functions are constructed automatically for you.
They specify the context of these tests. This context is used, for
-instance, by the GUI in Komodo to locate the test function and the
-code being tested.
+instance, by the GUI in Komodo Edit/IDE to locate the test function
+and the code being tested.
\begin{lyxcode}
\#\#~Test~unit~'Square'
@@ -770,7 +778,7 @@
So, with test units associated to packages, you have a very convenient
way to run these tests, including from the Komodo GUI. With just a
little bit more coding you can also include these test units in the
-\command{R CMD check} process of your packages. You do thit by means
+\command{R CMD check} process of your packages. You do this by means
of examples in a help page (we prefer to use \textbf{examples}, instead
of \file{/tests} in the \command{R CMD check} process, because examples
offer a more flexible way to run tests and you can also run them in
@@ -781,10 +789,11 @@
with the case of the \pkg{svUnit} package itself):
\begin{itemize}
\item Define a \file{.Rd} help file in the \file{/man} subdirectory called
-\file{unitTests.Rd} (or whatever name you prefer).
+\file{unitTests.<mypackage>.Rd} where <mypackage> is the name of
+your package (or whatever name you prefer).
\item Fill the \file{.Rd} file, making sure that you define an alias as
-\file{unitTests.myPKG}. Also place a little bit of information telling
-how users can run your test in an interactive session.
+\file{unitTests.<mypackage>}. Also place a little bit of information
+telling how users can run your test in an interactive session.
\item The important part of this file is, of course, the \code{\textbackslash{}examples\{\}}
section. You must first clear the log, then run each test, and then,
call the \code{errorLog()} function. That function looks if one or
@@ -796,9 +805,10 @@
packages, that is, they will run silently each time you check your
package if no error occurs, but will produce a detailed report in
case of problems.
-\item Here is how your \file{.Rd} file should looks like:\end{itemize}
+\item Here is how your \file{.Rd} file should looks like (exemple of the
+\pkg{svUnit} package):\end{itemize}
\begin{lyxcode}
-\textbackslash{}name\{unitTests\}
+\textbackslash{}name\{unitTests.svUnit\}
\textbackslash{}alias\{unitTests.svUnit\}
@@ -832,57 +842,44 @@
\textbackslash{}examples\{
-library(svUnit)~
+if~(require(svUnit))~\{~
-\#~Make~sure~to~clear~log~first
+~~~~clearLog()
-clearLog()
+~~~~runTest(svSuite(\textquotedbl{}package:svUnit\textquotedbl{}),~\textquotedbl{}svUnit\textquotedbl{})
+~~~~\#\#~Possibly~run~other~tests~here...
+~~~~errorLog()
-\#~Run~all~test~units~defined~in~'svUnit'~package
-
-(runTest(svSuite(\textquotedbl{}package:svUnit\textquotedbl{}),~\textquotedbl{}svUnit\textquotedbl{}))~
-
-
-
-\textbackslash{}donttest\{~
-
-\#~These~tests~are~not~run~in~R~CMD~check~but~will~be~with
-
-\#~example(unitTests.svUnit)
-
-\#~Run~all~test~units~defined~in
-
-\#~the~/unitTests/VirtualClass~subdir
-
-(runTest(svSuite(\textquotedbl{}package:svUnit~(VirtualClass)\textquotedbl{}),
-
-~~~~\textquotedbl{}VirtualClass\textquotedbl{}))
-
\}
-
-
-\#~Check~errors~at~the~end~of~the~process
-
-\#(required~to~interrupt~R~CMD~check)
-
-errorLog()
-
\}
\textbackslash{}keyword\{utilities\}~
\end{lyxcode}
-Also, this mechanisms, associated with examples, provides a very convenient
+Note, however, that if the package \pkg{svUnit} is not available
+on the computer where you run \command{R CMD check}, your tests are
+silently ignored (\code{require()} issues a warning, but that does
+not prevent the checking process to continue). This is an intended
+feature in order to allow compilation of your package without requiring
+\pkg{svUnit}. Hence, dependence to \pkg{svUnit} is less strict and
+also allows you to check your tests using \pkg{RUnit} (but you have
+to write a dedicated function for that). Still to keep such a less
+strict dependence on \pkg{svUnit}, you should add \code{svUnit}
+in the \code{Suggests:} field in the \file{DESCRIPTION} file of
+your package, not in \code{Depends:} or \code{Imports:} fields (except
+if you use \pkg{svUnit} for other purposes that testing your package
+using the mechanism discussed here, of course.
+
+Also, this approach, associated with examples, provides a very convenient
and easy way to test a package from the command line in an interactive
session by running:
<<>>=
-library(svUnit)
example(unitTests.svUnit)
@
@@ -902,7 +899,7 @@
these to actual directories where the test unit files are located).
Also, if you specify \code{package:myPkg (subgroup)}, you will include
the test units defined in \file{/unitTests/subgroup} in the package
-\pkg{myPkg}. Of course, you will be able to add also test units defined
+\pkg{myPkg}. Of course, you will be able to also add test units defined
in custom directories, outside of \R{} packages (for instance for
integration of \emph{harness tests} that check cross-packages, or
multi-packages features of your application).
@@ -917,32 +914,32 @@
is just a question of constructing a test suite, and then, applying
the \code{makeUnit()} function to this \var{svSuite} object.
-Before we apply all this, you should also know one more function:
-\code{svSuiteList()}. This function lists all test units and test
-functions available in your system at a given time. So, you don’t
-need to manually create lists of components. You are better to list
-them automatically. Of course, this function has a lot of arguments
-for listing only test units in packages, only test functions, specifying
-where (in which environment) the test functions are located, adding
-custom directories where to look for test units, etc, etc. See the
-online help of this function for the description of all these arguments.
-One argument is particularly important: \code{excludeList =}. This
-argument defines one or several regular expressions that are used
-as filters to hide items from the list. This is required, since you
-will certainly not want to run again and again, let’s say, the example
-tests associated with the \pkg{svUnit} package (\pkg{svUnit} must
-be loaded in memory to run the tests, so its tests examples will always
-be listed by \code{svSuiteList()},... unless you define an adequate
-filter expression that will exclude them from your list)! As the default
-argument suggests it, the regular expression for list exclusion could
-also be recorded in \code{options(svUnit.excludeList = ...)}. Here
-is how it works:
+Before we apply all this, you should also know the existence of one
+more function: \code{svSuiteList()}. This function lists all test
+units and test functions available in your system at a given time.
+So, you don’t need to manually create lists of components. You are
+better to list them automatically. Of course, this function has a
+lot of arguments for listing only test units in packages, only test
+functions, specifying where (in which environment) the test functions
+are located, adding custom directories where to look for test units,
+etc, etc. See the online help of this function for the description
+of all these arguments. One argument is particularly important: \code{excludeList =}.
+This argument defines one or several regular expressions that are
+used as filters to hide items from the list. This is required, since
+you will certainly not want to run again and again, let’s say, the
+example tests associated with the \pkg{svUnit} package (\pkg{svUnit}
+must be loaded in memory to run the tests, so its tests examples will
+always be listed by \code{svSuiteList()},... unless you define an
+adequate filter expression that will exclude them from your list)!
+As the default argument suggests it, the regular expression for list
+exclusion could also be recorded in \code{options(svUnit.excludeList = ...)}.
+Here is how it works:
<<>>=
-# Reset default exclusion list
+## Reset default exclusion list
options(svUnit.excludeList = c("package:sv", "package:RUnit"))
-# List all currently available tests
+## List all currently available tests
svSuiteList()
@
@@ -954,7 +951,7 @@
<<>>=
-# Clear exclusion list
+## Clear exclusion list
options(svUnit.excludeList = NULL)
svSuiteList()
@
@@ -973,15 +970,15 @@
Now let’s make a test unit using tests collected in this suite:
-<<>>=
+<<eval = FALSE>>=
myUnit <- makeUnit(mySuite, name = "ExampleTests")
file.show(myUnit, delete.file = TRUE)
@
This produces a file named \file{runitExampleTests.R} located (by
-default) in the \R{} temporary directory, and which coleects all
-tests in the user's workspace (either as \var{svTest} objects, or
-as tests attached to other objects), plus tests suites in packages
+default) in the \R{} temporary directory, and which collects together
+all tests in the user's workspace (either as \var{svTest} objects,
+or as tests attached to other objects), plus tests suites in packages
that are \textbf{not} in the exclusion list. Running all tests in
your suite is very simple. You still use \code{runTest()} as usual,
but this time, you apply it to your \var{svSuite} object:
@@ -998,13 +995,13 @@
of the suite manually (see online help).
-\section{Using svUnit with Komodo/SciViews}
+\section{Using svUnit with SciViews Komodo}
-If you use the Komodo GUI (see \url{http://www.sciviews.org/SciViews-K}),
+If you use the SciViews Komodo GUI (see \url{http://www.sciviews.org/SciViews-K}),
you can integrate \pkg{svUnit} tests in this IDE and display reports
in a convenient hierarchical tree presentation (Fig. \ref{fig:KomodoRUnit}).
-If \R{} is started from within Komodo (with the \SciViews{-K} and
-\SciViews{-K Unit} plugins installed), then, loading the \pkg{svUnit}
+If \R{} is started from within Komodo Edit or IDE (with the \SciViews{-K}
+and \SciViews{-K Unit} plugins installed), then, loading the \pkg{svUnit}
package in \R{} automatically installs the \textbf{R Unit} side panel
in Komodo at right. Its use should be straightforward:
Modified: pkg/svUnit/inst/doc/svUnit.lyx
===================================================================
--- pkg/svUnit/inst/doc/svUnit.lyx 2010-09-05 16:09:00 UTC (rev 286)
+++ pkg/svUnit/inst/doc/svUnit.lyx 2010-09-05 16:10:46 UTC (rev 287)
@@ -71,7 +71,7 @@
\end_layout
\begin_layout Date
-Version 0.7-2, 2010-05-17
+Version 0.7-3, 2010-09-05
\end_layout
\begin_layout Author
@@ -160,7 +160,7 @@
\begin_layout Itemize
There is no way to choose one or several tests selectively: all are run
- or not (depending on command line options) during package testing.
+ or not (depending on command line options) during package checking.
\end_layout
\begin_layout Itemize
@@ -579,7 +579,7 @@
\end_inset
is, there is no tools to integrate the test suite in a given development
- environment (IDE) or graphical user interface (GUI).
+ environment (IDE) or graphical user interface (GUI), as far as we know.
In particular, there is no real-time reporting mechanism used to easy the
\emph on
@@ -767,7 +767,7 @@
\end_inset
- procedures to extract its content.
+ procedures to extract some content.
Finally, the concept of test units as sourceable files on disk is a nice
idea, but it is too rigid for quick writing test cases for objects not
associated (yet) with an
@@ -883,7 +883,7 @@
\end_inset
-), on top of Komodo Edit (
+), on top of Komodo Edit or IDE (
\begin_inset Flex URL
status collapsed
@@ -906,8 +906,8 @@
\end_inset
- from any GUI/IDE, and the Komodo Edit implementation could be used as an
- example to program similar integration panels for other
+ from any GUI/IDE, and the Komodo Edit/IDE implementation could be used
+ as an example to program similar integration panels for other
\begin_inset Flex R
status collapsed
@@ -1096,7 +1096,7 @@
1.9.0.
However, if you would like to use its interactive mode in a GUI editor,
- you must also install Komodo Edit and
+ you must also install Komodo Edit or Komodo IDE and
\begin_inset Flex SciViews
status collapsed
@@ -1107,7 +1107,7 @@
\end_inset
-K.
- The procedure is explaned at
+ The procedure is explaned here:
\begin_inset Flex URL
status collapsed
@@ -1168,12 +1168,12 @@
\begin_layout Plain Layout
- checkEqualsNumeric(10, Square(3)) # This intentionally fails
+ checkEqualsNumeric(10, Square(3)) # This intentionally fails
\end_layout
\begin_layout Plain Layout
- checkEqualsNumeric(9, SSSquare(3)) # This raises error
+ checkEqualsNumeric(9, SSSquare(3)) # This raises error
\end_layout
\begin_layout Plain Layout
@@ -1270,7 +1270,7 @@
\begin_layout Standard
You ensure that code you write in your
\begin_inset Flex R
-status open
+status collapsed
\begin_layout Plain Layout
@@ -1370,7 +1370,7 @@
\begin_layout Plain Layout
-# Create two R functions that include their own test cases
+## Create two R functions that include their own test cases
\end_layout
\begin_layout Plain Layout
@@ -1443,7 +1443,7 @@
\begin_layout Plain Layout
-# Add a separate test case
+## Add a separate test case
\end_layout
\begin_layout Plain Layout
@@ -1458,12 +1458,12 @@
\begin_layout Plain Layout
- v <- c(1, 2, 3) # The reference
+ v <- c(1, 2, 3) # The reference
\end_layout
\begin_layout Plain Layout
- w <- 1:3 # The value to compare to the reference
+ w <- 1:3 # The value to compare to the reference
\end_layout
\begin_layout Plain Layout
@@ -1607,11 +1607,11 @@
\end_inset
- is making the difference between a test that
+ is making the distinction between a test that
\series bold
fails
\series default
- (the code is run correctly, but the result is different what was expected)
+ (the code is run correctly, but the result is different from what was expected)
and code that raises
\series bold
error
@@ -1819,7 +1819,7 @@
\end_inset
.
- This (misspecified) test shows how
+ This test shows how
\begin_inset Flex CharStyle:Pkg
status collapsed
@@ -2544,7 +2544,7 @@
\begin_layout Plain Layout
-# Clear test exclusion list for running all test suites
+## Clear test exclusion list for running all test suites
\end_layout
\begin_layout Plain Layout
@@ -2554,7 +2554,7 @@
\begin_layout Plain Layout
-# Clear the logger
+## Clear the logger
\end_layout
\begin_layout Plain Layout
@@ -2564,7 +2564,7 @@
\begin_layout Plain Layout
-# Run all currently defined tests
+## Run all currently defined tests
\end_layout
\begin_layout Plain Layout
@@ -2574,7 +2574,7 @@
\begin_layout Plain Layout
-# Get some statistics
+## Get some statistics
\end_layout
\begin_layout Plain Layout
@@ -2584,7 +2584,7 @@
\begin_layout Plain Layout
-# A slightly different presentation than with print
+## A slightly different presentation than with print
\end_layout
\begin_layout Plain Layout
@@ -2594,7 +2594,7 @@
\begin_layout Plain Layout
-# Metadata collected on the machine where tests are run
+## Metadata collected on the machine where tests are run
\end_layout
\begin_layout Plain Layout
@@ -2604,7 +2604,7 @@
\begin_layout Plain Layout
-# List content of the log
+## List content of the log
\end_layout
\begin_layout Plain Layout
@@ -2913,7 +2913,7 @@
\begin_layout Plain Layout
-# Turn this function into a test
+## Turn this function into a test
\end_layout
\begin_layout Plain Layout
@@ -2969,7 +2969,7 @@
\end_inset
object, is allowed to live on its own (for instance, in the user's workspace,
- or anywhere you like.
+ or anywhere you like).
It can be defined in a
\begin_inset Flex R
status collapsed
@@ -3001,7 +3001,7 @@
\end_inset
- where test must always be located in a unit test).
+ where test must always be located in a unit test file on disk).
In
\begin_inset Flex CharStyle:Pkg
status collapsed
@@ -3132,7 +3132,7 @@
\begin_layout Plain Layout
-# A very simple function
+## A very simple function
\end_layout
\begin_layout Plain Layout
@@ -3146,7 +3146,7 @@
\begin_layout Plain Layout
-# A test case to associate with the Square() function
+## A test case to associate with the Square() function
\end_layout
\begin_layout Plain Layout
@@ -3363,19 +3363,9 @@
\end_inset
, one can define such test units, and they are made code compatible between
- the two implementations (at least for version 0.4-17 of
-\begin_inset Flex CharStyle:Pkg
-status collapsed
-
-\begin_layout Plain Layout
-RUnit
+ the two implementations.
\end_layout
-\end_inset
-
-).
-\end_layout
-
\begin_layout Standard
A test unit is a sourceable text file that contains one or more test functions,
plus possibly
@@ -3478,7 +3468,7 @@
\begin_layout Plain Layout
-<<>>=
+<<eval = FALSE>>=
\end_layout
\begin_layout Plain Layout
@@ -3591,8 +3581,8 @@
functions are constructed automatically for you.
They specify the context of these tests.
- This context is used, for instance, by the GUI in Komodo to locate the
- test function and the code being tested.
+ This context is used, for instance, by the GUI in Komodo Edit/IDE to locate
+ the test function and the code being tested.
\end_layout
\begin_layout LyX-Code
@@ -4000,7 +3990,7 @@
\end_inset
process of your packages.
- You do thit by means of examples in a help page (we prefer to use
+ You do this by means of examples in a help page (we prefer to use
\series bold
examples
\series default
@@ -4106,12 +4096,12 @@
status collapsed
\begin_layout Plain Layout
-unitTests.Rd
+unitTests.<mypackage>.Rd
\end_layout
\end_inset
- (or whatever name you prefer).
+ where <mypackage> is the name of your package (or whatever name you prefer).
\end_layout
\begin_layout Itemize
@@ -4130,7 +4120,7 @@
status collapsed
\begin_layout Plain Layout
-unitTests.myPKG
+unitTests.<mypackage>
\end_layout
\end_inset
@@ -4214,13 +4204,23 @@
\end_inset
- file should looks like:
+ file should looks like (exemple of the
+\begin_inset Flex CharStyle:Pkg
+status collapsed
+
+\begin_layout Plain Layout
+svUnit
\end_layout
+\end_inset
+
+ package):
+\end_layout
+
\begin_layout LyX-Code
\backslash
-name{unitTests}
+name{unitTests.svUnit}
\end_layout
\begin_layout LyX-Code
@@ -4304,27 +4304,31 @@
\end_layout
\begin_layout LyX-Code
-library(svUnit)
+if (require(svUnit)) {
\end_layout
\begin_layout LyX-Code
-# Make sure to clear log first
+ clearLog()
\end_layout
\begin_layout LyX-Code
-clearLog()
+ runTest(svSuite("package:svUnit"), "svUnit")
\end_layout
\begin_layout LyX-Code
+ ## Possibly run other tests here...
+\end_layout
+\begin_layout LyX-Code
+ errorLog()
\end_layout
\begin_layout LyX-Code
-# Run all test units defined in 'svUnit' package
+}
\end_layout
\begin_layout LyX-Code
[TRUNCATED]
To get the complete diff run:
svnlook diff /svnroot/sciviews -r 287
More information about the Sciviews-commits
mailing list