New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

`test_if` function? #141

Closed
cboettig opened this Issue Apr 2, 2014 · 7 comments

Comments

Projects
None yet
2 participants
@cboettig
Contributor

cboettig commented Apr 2, 2014

Would it be appropriate to have a function to support conditional testing, for instance, tests to run only if an API was available, and would otherwise simply inform the user that certain tests couldn't be run but avoid failing the check? It seems this behavior exists in other test suites, e.g. php on skipping-tests.

Or perhaps there's a natural way to do this already? (This issue is potentially related to the httr issue #93)

@hadley

This comment has been minimized.

Member

hadley commented Apr 7, 2014

Could you spell out a bit more how you'd expect the input and output might look?

Maybe related to #136?

@cboettig

This comment has been minimized.

Contributor

cboettig commented Apr 7, 2014

Sure, I was thinking something like the following (though you may imagine a more elegant construction):

test_if("Internet connection is available", { 
    ping_API() # Some function that returns TRUE only if successful, 
                       # otherwise the tests are not run and a warning is produced 
                       # that some tests not run because 'internet connection is available' failed 
     },
     { test_that("A bunch of tests that rely on the API being available", { 
        # Usual test_that construction
      })
  })
@hadley

This comment has been minimized.

Member

hadley commented Apr 9, 2014

I was thinking of an interface more like like:

test_that("A bunch of tests that rely on the API being available", { 
  if (!ping_API()) skip("Internet connection is available") 

  expect_equal(a, b)
  expect_equal(c, d)
})

That would be a bit more verbose because you'd need to repeat the check in each test block, but skip() would be implemented in such a way that you could write:

check_API <- function() {
  if (!ping_API()) skip("Internet connection is available") 
}

test_that("A bunch of tests that rely on the API being available", { 
  check_API()

  expect_equal(a, b)
  expect_equal(c, d)
})

This would have the advantage that you'd see how many tests were skipped. skip() would be implemented something like this:

skip <- function(message = NULL, call = sys.call(-1)) {
  cond <- structure(
    list(message = message, call = call),
    class = c("skip", "condition")
  )

  stop(cond)
}
@cboettig

This comment has been minimized.

Contributor

cboettig commented Apr 9, 2014

looks good to me

On Wed, Apr 9, 2014 at 2:22 PM, Hadley Wickham notifications@github.comwrote:

I was thinking of an interface more like like:

test_that("A bunch of tests that rely on the API being available", { if (!ping_API()) skip("Internet connection is available")
expect_equal(a, b) expect_equal(c, d)})

That would be a bit more verbose because you'd need to repeat the check in
each test block, but skip() would be implemented in such a way that you
could write:

check_API <- function() { if (!ping_API()) skip("Internet connection is available") }
test_that("A bunch of tests that rely on the API being available", { check_API()
expect_equal(a, b) expect_equal(c, d)})

This would have the advantage that you'd see how many tests were skipped.

Reply to this email directly or view it on GitHubhttps://github.com//issues/141#issuecomment-40018156
.

Carl Boettiger
UC Santa Cruz
http://carlboettiger.info/

@hadley

This comment has been minimized.

Member

hadley commented Sep 17, 2014

How should the results look in the basic summary reporter? Is this ok?

Basic tests : ..S.....

Should the text of the skipped message be printed? If so, how do you match up the text to the test?

@cboettig

This comment has been minimized.

Contributor

cboettig commented Sep 17, 2014

That summary looks good to me. If printing the text, I would prepend it
with an S or a [Skipped] tag. At the summary level though I'd be fine if
the text message was simply suppressed though.

On Wed, Sep 17, 2014 at 2:27 AM, Hadley Wickham notifications@github.com
wrote:

How should the results look in the basic summary reporter? Is this ok?

Basic tests : ..S.....

Should the text of the skipped message be printed? If so, how do you match
up the text to the test?


Reply to this email directly or view it on GitHub
#141 (comment).

Carl Boettiger
UC Santa Cruz
http://carlboettiger.info/

@hadley

This comment has been minimized.

Member

hadley commented Sep 17, 2014

Ok, I think this is done then :)

@hadley hadley closed this Sep 17, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment