Code Monkey home page Code Monkey logo

Comments (1)

michaelquinn32 avatar michaelquinn32 commented on May 21, 2024

My examples tend to focus on local variables that aren't expensive to compute. Your example is a bit like that too, and it shouldn't be a problem to run that code every time. Each patrick iteration should be in a clean environment.

I'd rewrite your lintr example like this, which is more in line with the docs:

generate_cases <- function() {
  # Note: cases indicated by "*" are whole numbers, but don't lint because the user has
  #   effectively declared "this is a double" much as adding '.0' is otherwise accepted.
  cases <- tibble::tribble(
            ~num_value_str, ~should_lint,
                     "Inf",        FALSE,
                     "NaN",        FALSE,
                    "TRUE",        FALSE,
                    # ... And many more cases ...
                    "8.0i",        FALSE
  )
  # for convenience of coercing these to string (since tribble doesn't support auto-conversion)
  int_max <- .Machine[["integer.max"]]  # largest number that R can represent as an integer
  cases_int_max <- tibble::tribble(
    ~num_value_str, ~should_lint,
    -int_max - 1.0,        FALSE,
          -int_max,         TRUE,
           int_max,         TRUE,
     int_max + 1.0,        FALSE           int_max,         TRUE,
     int_max + 1.0,        FALSE
  )
  )
  cases_int_max$num_value_str <- as.character(cases_int_max$num_value_str)
  cases <- rbind(cases, cases_int_max)
  cases$.test_name <- sprintf("num_value_str=%s, should_lint=%s", cases$num_value_str, cases$should_lint)
  cases
}

patrick::with_parameters_test_that(
  "single numerical constants are properly identified ",
  {
    linter <-  implicit_integer_linter()
    expect_lint(num_value_str, if (should_lint) "Integers should not be implicit", linter)
  },
  .cases = generate_cases()
)

But I can see some value here for cases where some of the values needed in the parameterized test are expensive to compute.
The closes parallel I see here is the difference between setup and setupClass in Python.
https://stackoverflow.com/questions/23667610/what-is-the-difference-between-setup-and-setupclass-in-python-unittest

When using parameterized tests, setUp is called every time. This is for a clean environment, like you said. You
use setUpClass when you want a (usually readonly) object that might take a lot of time. Adding data to a database
for the test is one good use.

I'll see what I can do here.

from patrick.

Related Issues (14)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.