Repository navigation
test_that() fails in interactive mode when there are several failures within the same expectation. #279
Description
> test_that("everything goes normal", {
+ expect_equal(as.character(5), 5)
+ })
Error in vapply(failures, as.character, character(1)) :
values must be length 1,
but FUN(X[[1]]) result is length 2
> get_reporter()$failures[[1]]
Not expected: as.character(5) not equal to 5
Modes: numeric, character. Not expected: as.character(5) not equal to 5
target is numeric, current is character.
From what I tracked down, there are several problems:
- the "worst" one is that failures don't get cleaned up in the reporter if the function
end_test()throws an error, which prevents further use of the package. A quick fix would be to flush it first.
Then, either: format.expectation(called byas.character) should collapse the severalfailure_msgof the expectation.- Only one
failure_msgshould be allowed.
Activity
[-]test_that() fails in interactive mode when there is several failures within the same expectation.[/-][+]test_that() fails in interactive mode when there are several failures within the same expectation.[/+]quick fix for vapply() error when a failure has several messages in i…
antoine-lizee commentedon Jul 15, 2015
This first PR solves 1. and 2. in a pretty stupid way. I still don't know about 3. Are failures supposed to have several messages?
correct fallback for compare.numeric() - fixes r-lib#279
antoine-lizee commentedon Jul 16, 2015
This PR is the right fix. The problem was coming from
compare.numericthat was behaving differently thancompare.default(the fallback ofcompare.character).My diagnostic repex:
Should I add a better failover for the
end_test()method of the reporter? This still could be a problem later on. (point (1.) above) I could keep something along the lines of my first PR or have something like ainstead. Or just let it be :-).
antoine-lizee commentedon Sep 24, 2015
Thanks!