add srr documentation in tests/

R/srr-stats-standards.R

@@ -1,12 +1,5 @@
 #' srr_stats
 #'
-#' All of the following standards initially have `@srrstatsTODO` tags.
-#' These may be moved at any time to any other locations in your code.
-#' Once addressed, please modify the tag from `@srrstatsTODO` to `@srrstats`,
-#' or `@srrstatsNA`, ensuring that references to every one of the following
-#' standards remain somewhere within your code.
-#' (These comments may be deleted at any time.)
-#'
 #' @srrstatsVerbose TRUE
 #'
 #' @srrstats {G1.5} *Software should include all code necessary to reproduce results which form the basis of performance claims made in associated publications.*
@@ -37,37 +30,11 @@
 #' @srrstats {G3.0} *Statistical software should never compare floating point numbers for equality. All numeric equality comparisons should either ensure that they are made between integers, or use appropriate tolerances for approximate equality.*
 #' @srrstats {G3.1} *Statistical software which relies on covariance calculations should enable users to choose between different algorithms for calculating covariances, and should not rely solely on covariances from the `stats::cov` function.*
 #' @srrstats {G3.1a} *The ability to use arbitrarily specified covariance methods should be documented (typically in examples or vignettes).*
-#' @srrstats {G5.0} *Where applicable or practicable, tests should use standard data sets with known properties (for example, the [NIST Standard Reference Datasets](https://www.itl.nist.gov/div898/strd/), or data sets provided by other widely-used R packages).*
-#' @srrstats {G5.1} *Data sets created within, and used to test, a package should be exported (or otherwise made generally available) so that users can confirm tests and run examples.*
-#' @srrstats {G5.2} *Appropriate error and warning behaviour of all functions should be explicitly demonstrated through tests. In particular,*
 #' @srrstats {G5.2a} *Every message produced within R code by `stop()`, `warning()`, `message()`, or equivalent should be unique*
-#' @srrstats {G5.2b} *Explicit tests should demonstrate conditions which trigger every one of those messages, and should compare the result with expected values.*
 #' @srrstats {G5.4a} *For new methods, it can be difficult to separate out correctness of the method from the correctness of the implementation, as there may not be reference for comparison. In this case, testing may be implemented against simple, trivial cases or against multiple implementations such as an initial R implementation compared with results from a C/C++ implementation.*
-#' @srrstats {G5.4b} *For new implementations of existing methods, correctness tests should include tests against previous implementations. Such testing may explicitly call those implementations in testing, preferably from fixed-versions of other software, or use stored outputs from those where that is not possible.*
 #' @srrstats {G5.4c} *Where applicable, stored values may be drawn from published paper outputs when applicable and where code from original implementations is not available*
-#' @srrstats {G5.6} **Parameter recovery tests** *to test that the implementation produce expected results given data with known properties. For instance, a linear regression algorithm should return expected coefficient values for a simulated data set generated from a linear model.*
-#' @srrstats {G5.6a} *Parameter recovery tests should generally be expected to succeed within a defined tolerance rather than recovering exact values.*
-#' @srrstats {G5.6b} *Parameter recovery tests should be run with multiple random seeds when either data simulation or the algorithm contains a random component. (When long-running, such tests may be part of an extended, rather than regular, test suite; see G5.10-4.12, below).*
-#' @srrstats {G5.7} **Algorithm performance tests** *to test that implementation performs as expected as properties of data change. For instance, a test may show that parameters approach correct estimates within tolerance as data size increases, or that convergence times decrease for higher convergence thresholds.*
-#' @srrstats {G5.8} **Edge condition tests** *to test that these conditions produce expected behaviour such as clear warnings or errors when confronted with data with extreme properties including but not limited to:*
-#' @srrstats {G5.8a} *Zero-length data*
-#' @srrstats {G5.8b} *Data of unsupported types (e.g., character or complex numbers in for functions designed only for numeric data)*
-#' @srrstats {G5.8c} *Data with all-`NA` fields or columns or all identical fields or columns*
-#' @srrstats {G5.8d} *Data outside the scope of the algorithm (for example, data with more fields (columns) than observations (rows) for some regression algorithms)*
-#' @srrstats {G5.9} **Noise susceptibility tests** *Packages should test for expected stochastic behaviour, such as through the following conditions:*
-#' @srrstats {G5.9a} *Adding trivial noise (for example, at the scale of `.Machine$double.eps`) to data does not meaningfully change results*
-#' @srrstats {G5.10} *Extended tests should included and run under a common framework with other tests but be switched on by flags such as as a `<MYPKG>_EXTENDED_TESTS="true"` environment variable.* - The extended tests can be then run automatically by GitHub Actions for example by adding the following to the `env` section of the workflow:
-#' @srrstats {G5.11} *Where extended tests require large data sets or other assets, these should be provided for downloading and fetched as part of the testing workflow.*
-#' @srrstats {G5.12} *Any conditions necessary to run extended tests such as platform requirements, memory, expected runtime, and artefacts produced that may need manual inspection, should be described in developer documentation such as a `CONTRIBUTING.md` or `tests/README.md` file.*
 #' @srrstats {RE4.8} *Response variables, and associated "metadata" where applicable.*
 #' @srrstats {RE5.0} *Scaling relationships between sizes of input data (numbers of observations, with potential extension to numbers of variables/columns) and speed of algorithm.*
-#' @srrstats {RE7.0} *Tests with noiseless, exact relationships between predictor (independent) data.*
-#' @srrstats {RE7.0a} In particular, these tests should confirm ability to reject perfectly noiseless input data.
-#' @srrstats {RE7.1} *Tests with noiseless, exact relationships between predictor (independent) and response (dependent) data.*
-#' @srrstats {RE7.1a} *In particular, these tests should confirm that model fitting is at least as fast or (preferably) faster than testing with equivalent noisy data (see RE2.4b).*
-#' @srrstats {RE7.2} Demonstrate that output objects retain aspects of input data such as row or case names (see **RE1.3**).
-#' @srrstats {RE7.3} Demonstrate and test expected behaviour when objects returned from regression software are submitted to the accessor methods of **RE4.2**--**RE4.7**.
-#' @srrstats {RE7.4} Extending directly from **RE4.15**, where appropriate, tests should demonstrate and confirm that forecast errors, confidence intervals, or equivalent values increase with forecast horizons.
 #' @noRd
 NULL
 

tests/README.md

@@ -0,0 +1,6 @@
+The tests:
+
+1. fepoisson time is the same adding noise to the data (`test-fepoisson.R`)
+2. fenegbin time is the same adding noise to the data (`test-fenegbin.R`)
+
+Are commeted because these take 1-2 minutes to run and create a CRAN note.

tests/testthat/test-feglm.R

@@ -1,3 +1,31 @@
+#' srr_stats (tests)
+#' 
+#' @srrstatsVerbose TRUE
+#' 
+#' @srrstats {G5.0} *Where applicable or practicable, tests should use standard data sets with known properties (for example, the [NIST Standard Reference Datasets](https://www.itl.nist.gov/div898/strd/), or data sets provided by other widely-used R packages).*
+#' @srrstats {G5.1} *Data sets created within, and used to test, a package should be exported (or otherwise made generally available) so that users can confirm tests and run examples.*
+#' @srrstats {G5.2} *Appropriate error and warning behaviour of all functions should be explicitly demonstrated through tests. In particular,*
+#' @srrstats {G5.2b} *Explicit tests should demonstrate conditions which trigger every one of those messages, and should compare the result with expected values.*
+#' @srrstats {G5.4b} *For new implementations of existing methods, correctness tests should include tests against previous implementations. Such testing may explicitly call those implementations in testing, preferably from fixed-versions of other software, or use stored outputs from those where that is not possible.*
+#' @srrstats {G5.8} **Edge condition tests** *to test that these conditions produce expected behaviour such as clear warnings or errors when confronted with data with extreme properties including but not limited to:*
+#' @srrstats {G5.8a} *Zero-length data*
+#' @srrstats {G5.8b} *Data of unsupported types (e.g., character or complex numbers in for functions designed only for numeric data)*
+#' @srrstats {G5.8c} *Data with all-`NA` fields or columns or all identical fields or columns*
+#' @srrstats {G5.8d} *Data outside the scope of the algorithm (for example, data with more fields (columns) than observations (rows) for some regression algorithms)*
+#' @srrstats {G5.9} **Noise susceptibility tests** *Packages should test for expected stochastic behaviour, such as through the following conditions:*
+#' @srrstats {G5.9a} *Adding trivial noise (for example, at the scale of `.Machine$double.eps`) to data does not meaningfully change results*
+#' @srrstats {G5.10} *Extended tests should included and run under a common framework with other tests but be switched on by flags such as as a `<MYPKG>_EXTENDED_TESTS="true"` environment variable.* - The extended tests can be then run automatically by GitHub Actions for example by adding the following to the `env` section of the workflow:
+#' @srrstats {G5.11} *Where extended tests require large data sets or other assets, these should be provided for downloading and fetched as part of the testing workflow.*
+#' @srrstats {RE7.0} *Tests with noiseless, exact relationships between predictor (independent) data.*
+#' @srrstats {RE7.0a} In particular, these tests should confirm ability to reject perfectly noiseless input data.
+#' @srrstats {RE7.1} *Tests with noiseless, exact relationships between predictor (independent) and response (dependent) data.*
+#' @srrstats {RE7.1a} *In particular, these tests should confirm that model fitting is at least as fast or (preferably) faster than testing with equivalent noisy data (see RE2.4b).*
+#' @srrstats {RE7.2} Demonstrate that output objects retain aspects of input data such as row or case names (see **RE1.3**).
+#' @srrstats {RE7.3} Demonstrate and test expected behaviour when objects returned from regression software are submitted to the accessor methods of **RE4.2**--**RE4.7**.
+#' @srrstats {RE7.4} Extending directly from **RE4.15**, where appropriate, tests should demonstrate and confirm that forecast errors, confidence intervals, or equivalent values increase with forecast horizons.
+#' @noRd
+NULL
+
 test_that("feglm is similar to glm", {
   # Gaussian ----
 

tests/testthat/test-felm.R

@@ -1,3 +1,32 @@
+#' srr_stats (tests)
+#'
+#' @srrstatsVerbose TRUE
+#'
+#' @srrstats {G5.0} *Where applicable or practicable, tests should use standard data sets with known properties (for example, the [NIST Standard Reference Datasets](https://www.itl.nist.gov/div898/strd/), or data sets provided by other widely-used R packages).*
+#' @srrstats {G5.1} *Data sets created within, and used to test, a package should be exported (or otherwise made generally available) so that users can confirm tests and run examples.*
+#' @srrstats {G5.2} *Appropriate error and warning behaviour of all functions should be explicitly demonstrated through tests. In particular,*
+#' @srrstats {G5.2b} *Explicit tests should demonstrate conditions which trigger every one of those messages, and should compare the result with expected values.*
+#' @srrstats {G5.4b} *For new implementations of existing methods, correctness tests should include tests against previous implementations. Such testing may explicitly call those implementations in testing, preferably from fixed-versions of other software, or use stored outputs from those where that is not possible.*
+#' @srrstats {G5.7} **Algorithm performance tests** *to test that implementation performs as expected as properties of data change. For instance, a test may show that parameters approach correct estimates within tolerance as data size increases, or that convergence times decrease for higher convergence thresholds.*
+#' @srrstats {G5.8} **Edge condition tests** *to test that these conditions produce expected behaviour such as clear warnings or errors when confronted with data with extreme properties including but not limited to:*
+#' @srrstats {G5.8a} *Zero-length data*
+#' @srrstats {G5.8b} *Data of unsupported types (e.g., character or complex numbers in for functions designed only for numeric data)*
+#' @srrstats {G5.8c} *Data with all-`NA` fields or columns or all identical fields or columns*
+#' @srrstats {G5.8d} *Data outside the scope of the algorithm (for example, data with more fields (columns) than observations (rows) for some regression algorithms)*
+#' @srrstats {G5.9} **Noise susceptibility tests** *Packages should test for expected stochastic behaviour, such as through the following conditions:*
+#' @srrstats {G5.9a} *Adding trivial noise (for example, at the scale of `.Machine$double.eps`) to data does not meaningfully change results*
+#' @srrstats {G5.10} *Extended tests should included and run under a common framework with other tests but be switched on by flags such as as a `<MYPKG>_EXTENDED_TESTS="true"` environment variable.* - The extended tests can be then run automatically by GitHub Actions for example by adding the following to the `env` section of the workflow:
+#' @srrstats {G5.11} *Where extended tests require large data sets or other assets, these should be provided for downloading and fetched as part of the testing workflow.*
+#' @srrstats {RE7.0} *Tests with noiseless, exact relationships between predictor (independent) data.*
+#' @srrstats {RE7.0a} In particular, these tests should confirm ability to reject perfectly noiseless input data.
+#' @srrstats {RE7.1} *Tests with noiseless, exact relationships between predictor (independent) and response (dependent) data.*
+#' @srrstats {RE7.1a} *In particular, these tests should confirm that model fitting is at least as fast or (preferably) faster than testing with equivalent noisy data (see RE2.4b).*
+#' @srrstats {RE7.2} Demonstrate that output objects retain aspects of input data such as row or case names (see **RE1.3**).
+#' @srrstats {RE7.3} Demonstrate and test expected behaviour when objects returned from regression software are submitted to the accessor methods of **RE4.2**--**RE4.7**.
+#' @srrstats {RE7.4} Extending directly from **RE4.15**, where appropriate, tests should demonstrate and confirm that forecast errors, confidence intervals, or equivalent values increase with forecast horizons.
+#' @noRd
+NULL
+
 test_that("felm works", {
   m1 <- felm(mpg ~ wt | cyl, mtcars)
   m2 <- lm(mpg ~ wt + as.factor(cyl), mtcars)

tests/testthat/test-fenegbin.R

@@ -1,3 +1,11 @@
+#' srr_stats (tests)
+#'
+#' @srrstatsVerbose TRUE
+#'
+#' @srrstats {G5.12} *Any conditions necessary to run extended tests such as platform requirements, memory, expected runtime, and artefacts produced that may need manual inspection, should be described in developer documentation such as a `CONTRIBUTING.md` or `tests/README.md` file.*
+#' @noRd
+NULL
+
 test_that("fenegbin is similar to fixest", {
   # use one year or otherwise devtools::check() gives a warning about the time
   # it takes
@@ -27,3 +35,41 @@ test_that("fenegbin is similar to fixest", {
     rep(0, 4)
   )
 })
+
+# test_that("fenegbin time is the same adding noise to the data", {
+#   trade_panel2 <- trade_panel
+#   set.seed(200100)
+#   trade_panel2$trade2 <- trade_panel$trade + rbinom(nrow(trade_panel2), 1, 0.5) *
+#     .Machine$double.eps
+#   m1 <- fenegbin(
+#     trade ~ log_dist + lang + cntg + clny | exp_year + imp_year | pair,
+#     trade_panel2
+#   )
+#   m2 <- fenegbin(
+#     trade2 ~ log_dist + lang + cntg + clny | exp_year + imp_year | pair,
+#     trade_panel2
+#   )
+#   expect_equal(coef(m1), coef(m2))
+#   expect_equal(fixed_effects(m1), fixed_effects(m2))
+
+#   t1 <- rep(NA, 10)
+#   t2 <- rep(NA, 10)
+#   for (i in 1:10) {
+#     a <- Sys.time()
+#     m1 <- fenegbin(
+#       trade ~ log_dist + lang + cntg + clny | exp_year + imp_year | pair,
+#       trade_panel2
+#     )
+#     b <- Sys.time()
+#     t1[i] <- b - a
+
+#     a <- Sys.time()
+#     m2 <- fenegbin(
+#       trade2 ~ log_dist + lang + cntg + clny | exp_year + imp_year | pair,
+#       trade_panel2
+#     )
+#     b <- Sys.time()
+#     t2[i] <- b - a
+#   }
+#   expect_lte(abs(median(t1) - median(t2)), 0.05)
+# })

tests/testthat/test-fepoisson.R

@@ -1,3 +1,11 @@
+#' srr_stats (tests)
+#'
+#' @srrstatsVerbose TRUE
+#' 
+#' @srrstats {G5.12} *Any conditions necessary to run extended tests such as platform requirements, memory, expected runtime, and artefacts produced that may need manual inspection, should be described in developer documentation such as a `CONTRIBUTING.md` or `tests/README.md` file.*
+#' @noRd 
+NULL
+
 test_that("fepoisson is similar to fixest", {
   mod <- fepoisson(
     trade ~ log_dist + lang + cntg + clny | exp_year + imp_year | pair,
@@ -79,3 +87,41 @@ test_that("fepoisson is similar to fixest", {
     expect_lte(t_fepoisson, t_glm)
   }
 })
+
+# test_that("fepoisson time is the same adding noise to the data", {
+#   trade_panel2 <- trade_panel
+#   set.seed(200100)
+#   trade_panel2$trade2 <- trade_panel$trade + rbinom(nrow(trade_panel2), 1, 0.5) *
+#     .Machine$double.eps
+#   m1 <- fepoisson(
+#     trade ~ log_dist + lang + cntg + clny | exp_year + imp_year | pair,
+#     trade_panel2
+#   )
+#   m2 <- fepoisson(
+#     trade2 ~ log_dist + lang + cntg + clny | exp_year + imp_year | pair,
+#     trade_panel2
+#   )
+#   expect_equal(coef(m1), coef(m2))
+#   expect_equal(fixed_effects(m1), fixed_effects(m2))
+
+#   t1 <- rep(NA, 10)
+#   t2 <- rep(NA, 10)
+#   for (i in 1:10) {
+#     a <- Sys.time()
+#     m1 <- fepoisson(
+#       trade ~ log_dist + lang + cntg + clny | exp_year + imp_year | pair,
+#       trade_panel2
+#     )
+#     b <- Sys.time()
+#     t1[i] <- b - a
+
+#     a <- Sys.time()
+#     m2 <- fepoisson(
+#       trade2 ~ log_dist + lang + cntg + clny | exp_year + imp_year | pair,
+#       trade_panel2
+#     )
+#     b <- Sys.time()
+#     t2[i] <- b - a
+#   }
+#   expect_lte(abs(median(t1) - median(t2)), 0.05)
+# })