I'm currently trying to work out how best to use these reporters in a shell script that runs my tests.
To use a reporter using testthat or devtools your code looks like this:
devtools::test(my_dir, reporter = CheckReporter)
or equivalently
testthat::test_dir(my_dir, reporter = CheckReporter)
They reporter can also be defined as a string: the string corresponding to CheckReporter being "check"
`CheckReporter` and the other *Reporters are imported into your namespace as objects. you don't need to instantiate them `
For non-interactive use the appropriate reporters are:
CheckReporter, FailReporter, JUnitReporter, ListReporter, TapReporter, TeamcityReporter
For interactive use the appropriate reporters are:
DebugReporter, LocationReporter, MinimalReporter, ProgressReporter, RstudioReporter, SilentReporter, StopReporter, SummaryReporter
MultiReporter is used for combining results together
----
I find SummaryReporter the simplest to use when using R interactively.
TO BE FINISHED
----
Summaries of the available testthat reporter objects from within the testthat pdf
CheckReporter
R CMD check displays only the last 13 lines of the result, so this report is design to ensure that you see something useful there.
DebugReporter
This reporter will call a modified version of recover() on all broken expectations.
FailReporter
This reporter will simply throw an error if any of the tests failed. It is best combined with another reporter, such as the SummaryReporter.
JunitReporter
This reporter includes detailed results about each test and summaries, written to a file (or stdout) in jUnit XML format. This can be read by the Jenkins Continuous Integration System to report on a dashboard etc. Requires the xml2 package.
ListReporter
This reporter gathers all results, adding additional information such as test elapsed time, and test filename if available. Very useful for reporting.
LocationReporter
This reporter simply prints the location of every expectation and error. This is useful if you’re trying to figure out the source of a segfault, or you want to figure out which code triggers a C/C++ breakpoint
MinimalReporter
The minimal test reporter provides the absolutely minimum amount of information: whether each expectation has succeeded, failed or experienced an error. If you want to find out what the failures and errors actually were, you’ll need to run a more informative test reporter.
MultiReporter
This reporter is useful to use several reporters at the same time, e.g. adding a custom reporter without removing the current one.
ProgressReporter
This reporter is a reimagining of SummaryReporter desgined to make the most information available up front, while taking up less space overall. It is the default reporting reporter used by test_dir() and test_file().
RstudioReporter
This reporter is designed for output to RStudio. It produces results in any easily parsed form
SilentReporter
This reporter quietly runs all tests, simply gathering all expectations. This is helpful for programmatically inspecting errors after a test run. You can retrieve the results with the expectations() method.
StopReporter
The default reporter, executed when expect_that is run interactively. It responds by stop()ping on failures and doing nothing otherwise. This will ensure that a failing test will raise an error.
SummaryReporter
This is a reporter designed for interactive usage: it lets you know which tests have run successfully and as well as fully reporting information about failures and errors.
TapReporter
This reporter will output results in the Test Anything Protocol (TAP), a simple text-based interface between testing modules in a test harness. For more information about TAP, see http://testanything.org
TeamcityReporter
This reporter will output results in the Teamcity message format. For more information about Teamcity messages, see http://confluence.jetbrains.com/display/TCD7/Build+Script+Interaction+with+TeamCity
No comments:
Post a Comment