SCM Repository
[inlinedocs] / pkg / inlinedocs / inst / testfiles / prolog.r |
Log of /pkg/inlinedocs/inst/testfiles/prolog.r
Links to HEAD: | (view) (download) (annotate) |
Sticky Revision: |
Revision 394 - (view) (download) (annotate) - [select for diffs]
Added Mon Dec 23 15:36:20 2013 UTC (5 years, 1 month ago) by markus
File length: 184 byte(s)
0.) This is an intermediate commit, that will be followed by further tidying. I just got afraid to have to merge branches if I wait longer. 1.) The purposes of the committed changes are a) to enable unittesting for very small units (functions) with the help of a unit testing framework. b) to enable the detailed documentation of S4 methods in separate (signature specific) .Rd files and 2.) Details: a) Unittesting: Motivation: To implement the changes mentioned above I needed a facility to test very small parts of inlinedocs infrastructure. Just comparing results of all parts combined actions as in the already existent testcases turned out to be to fragile for my limited understanding of how inlinedocs parts work. Instead of hoping that package.skeleton.dx would still work after my change and having to write a rather complete result fixture I needed something that would test single functions against a very small fixture in order to learn what part they were intended to play or how they would have to be tweeaked. Existing test tools: Unfortunately it turned out that neither "Runit" nor "testthis" could be applied to test inlinedocs. The reason is that the crucial requirement of test independence was not fulfilled: I was horrified to notice that in both frameworks a test could be reproducibly triggered to fail by code in \emph{another} test. I could make out a combination of three factors that lead to this unexpected result: - the use of global options and the (necessary) use of environments in inlinedocs - the inability of both testframeworks to isolate such acrobatic behavior to a single test although the execution of tests in separated environments is even advertised (in both frameworks!) - the inability of R (at least as far as I know) to provide testframeworks with means of effective isolation Adapted test tool: To make \emph{independent} testing of units possible I went to the rather extreme measure of using a subprocess for each test. The machinery is implemented in .../testfiles/mm/isolatedTestRunner.R When a test is executed the following things happen: - inside the ...testfiles/mm/tmp a directory is created that reflects the name of the testfunction - source code for a RUnit testsuite (consisting of one test) and a runit.Testfile.R containing the testfunction is created - the suite is run (by means of Rscript ) and the result written to a file (if it crashes this will be recognized but of course not brake the calling process) - the result is collected by the isoloatedTestRunner and reported in a very preliminary fashion by isolatedTestrunner. (RUnit is also used on this level, but could be used more intensly to achieve the same level of reporting and ease of use) To run all tests just call ./isall.R For a single test run use ./Itest Both look nearly like typicla RUnit testsuite with the tiny differece of calling the isolatedTestRunner.R Proposed use: For future versions of inlinedocs I strongly recommend a mandatory extensive testsuite but for the moment I confined all my unittesting in the directory: .../testfiles/mm because I of course need your agreement, dispute, opinion or advise for such a change of infrastructure. At the moment I would just be happy if you run: isall.R in inlinedocs/inst/testfiles/mm/ before you commit, to see I some of the new tests are broken. b) Method documentation: For a generic with the name "GenericName" and the signature c("ClassNameA","ClassNameB") a file with the name GenericName-method-#ClassNameA#ClassNameB.Rd is created and populated using the same infrastructe that is used for functions for the actual definition, but a rather different approach to find the Generic (forGeneric is not similar enough to forFun to use forAll in both cases) I am still struggeling with documentation of operator methods since for them no "srcref" attribute seems to be available but I am working on this. Next Steps and Proposal: complete operator method description and cleanup (e.g. check if inlinedocs package itself still builds an passed cran checks;-))
This form allows you to request diffs between any two revisions of this file. For each of the two "sides" of the diff, enter a numeric revision.
R-Forge@R-project.org | ViewVC Help |
Powered by ViewVC 1.0.0 |