El vie., 7 sept. 2018 a las 15:28, Dirk Eddelbuettel
(<e...@debian.org>) escribió:
>
>
> On 7 September 2018 at 13:08, Gábor Csárdi wrote:
> | On Fri, Sep 7, 2018 at 12:29 PM Dirk Eddelbuettel <e...@debian.org> wrote:
> | >
> | >
> | > On 7 September 2018 at 09:27, Gábor Csárdi wrote:
> | > | When are users running tests for packages at all? The tests are by
> default
> | > | no even installed with the package. The only time I usually do this is
> when
> | >
> | > Which some people consider to be the wrong decision by testthat.
> |
> | How is testthat related to this? When you `R CMD INSTALL` a package,
> | AFAICT it does not install the test by default. Independently of what
> | testsuite you use.
>
> I presume you know the other per the bottom part of the email. Following the
> (very early best practive started by P Grosjean, M Maechler and others)
> tests/doRUnit.R always calls out to files in inst/tests or inst/unitTests.
>
> Which. Get. Installed.
>
> For every user. Automatically. A much better default.
>
> | > Base R has a set of functions
> | >
> | > tools::testInstalledBasic
> | > tools::testInstalledPackage
> | > tools::testInstalledPackages
> | >
> | > so that an _installed_ package can be tested. Unless, of course, it uses
> | > testthat. Matt Dowle just run into this (per a question on
> StackOverflow).
> | > RUnit, on the other hand, supports this.
> |
> | I am probably missing sg, but is this expected to run the Rcpp test suite?
> |
> | tools::testInstalledPackage("Rcpp", types = "tests")
> |
> | Because it takes 1ms to run and has no output.
>
> You probably need a) the required env var set and b) the RUnit test runner to
> loop over RUnit tests and c) make sure the dependent C++ files are compiled
> first which is why we have a wrapper in that package. But note that I never
> claimed it currently worked -- that test setup (being able to run from tests/
> and once installed) is more tricky for Rcpp due to the compilation.
>
> I did claim that by not giving the testthat user that option you are not
> helping.
> And I stand by that.
For the record, this is what the testthat paper in the R Journal says:
"[...] I recommend storing your tests in inst/tests/ (so users also
have access to them), then including one file in tests/ that runs all
of the package tests. The test_package(package_name) function makes
this easy. [...] This setup has the additional advantage that users
can make sure your package works correctly in their run-time
environment."
Iñaki
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
