Getting The Most Out Of
Test-Driven Development
For Shiny

Jakub Sobolewski

July 10, 2024

1. What is TDD?
2. How to do TDD?
3. Why use TDD?

In this session we’re going to answer three questions:

• What is Test-Driven Development?
• How to do it in R and how we can use it to develop Shiny apps.
• And last, but not least, why should we use it?

I hope that by the end of the session, you’ll have a better understanding of TDD and why it’s worth giving it a try.

What is TDD?

🏛️ A design technique.

📈 A guided evolution.

🧪 Tests first.

• It a technique in which tests help us design our code, it’s not really about testing.
• It is a guided evolution with clear feedback after each step.
• And last, but not least, it’s a process where we write tests before we write the production code.

3 steps of TDD

❌ Red

✅ Green

🔁 Refactor

3 steps of TDD

❌ Red

Write a failing test first. ⛔️

✅ Green

🔁 Refactor

There are 3 steps in TDD.

Red - this is where we start by writing a failing test. It will fail because the code we want to test doesn’t exist yet. It will fail as long as we don’t solve the problem we stated in the test.

This approach is the other way around to the test-last approach where we write tests to make them pass. It changes the dynamic between prodcution code and tests. In TDD we don’t try to prove that the code we wrote works as expected using test. We write code to accomplish what is stated in tests.

3 steps of TDD

❌ Red

✅ Green

Write the production code.

Only as much as needed to make tests pass. ✋

🔁 Refactor

1. Green - once we have at least one failing test, we can write production code to satisfy it.

Since we have tests, we can run them as often as we need. We have a reproducible way to check if the code we write works as expected. We don’t need to setup the environment by hand each time we sit down to write the code or to do a lot of clicking in the app, if we’re developing an app.

If the code does what we want it to, tests will pass.

1. We write only as much production code as needed to make tests pass. Why would we write more code, if tests are already satisfied? Don’t do it, You Ain’t Gonna Need It.

3 steps of TDD

❌ Red

✅ Green

🔁 Refactor

Don’t worry about breaking things.

Make code more readable and maintainable. 💄

1. Last step is refactoring - Were you ever afraid of refactoring your code because you thought you might break something? TDD helps you mitigate this problem. We have tests that ensure that the code works as expected. So we can be more liberal in changes we make to the code. If written well, tests don’t constrain us, they empower us to make bold changes.

2. We don’t only want to have working code, we want to have good code. We can spend some time in this step to make sure our code is clean and easy to understand.

Example

Let’s see in practice how the process looks like.

We’ll implament a simple function that adds numbers.

It will be a simple example, but it will show how the process works.

❌ Red

sum.R

#

test-sum.R

describe("my_sum", {
  it("should calculate the sum for multiple numbers", {
    fail("Not implemented")
  })
})

── Failure: my_sum: should calculate the sum for multiple numbers ──────────────
Not implemented

Error:
! Test failed

We write down a title of the first behavior we want to implement. This can be the simplest case, just to get us started.

The next step we’re about to do was the most scary part of TDD for me. But it was scary only at the beginning, when I started learning it.

How can we write a test, if there is no code to test?

❌ Red

sum.R

#

test-sum.R

describe("my_sum", {
  it("should calculate the sum for multiple numbers", {
    # Arrange
    numbers <- c(1, 2)

    # Act
    result <- my_sum(numbers)

    # Assert
    expect_equal(result, 3)
  })
})

── Error: my_sum: should calculate the sum for multiple numbers ────────────────
Error in `my_sum(numbers)`: could not find function "my_sum"

Error:
! Test failed

1. It’s useful to remember that each test consists of three parts:

• Setup
• Execution
• Assertion

We can use #Arrange, #Act, #Assert comments to split our tests into those distinct parts.

1. We start with the setup.

#Arrange is where we prepare the environment. This is where we need to figure out the inputs required to solve the problem.

This is very powerful, why? At this stage, we focus on what we need to be able to solve the problem. Not how we will solve it.

Without understanding the problem we won’t be able write down the test. And this is good, we won’t write any production code until we have the understanding of the problem. This helps us mitigate the risk of implementing the wrong solution.

1. #Act is where we call our code.

TDD gives us the freedom to experiment with interfaces.

We can try out a few different variants even before we start writing the production code, possibly saving a lot of time on refactoring.

The test you write is the first user of your code. The way you call your code from tests is the way you will call it from the production code. So, think about how you want to use your code and then write it down in a test.

1. In #Assert we focus on how to observe that the code works as expected.

Again, we won’t be able to do it without understanding the problem. We should know what is the expected output for given inputs.

Although we could skip writing down the assertion, but only for a few iterations of prototyping, to help us undestand the data better, and design the output we want.

So, in TDD we first define inputs and outputs, treating the not-yet-existing code as a black box.

This approach produces tests that don’t test implementation details. It’s impossible to do so since there is no implementation yet!

This makes tests focused on the behavior.

❌ Red

sum.R

my_sum <- function(x) {

}

test-sum.R

describe("my_sum", {
  it("should calculate the sum for multiple numbers", {
    # Arrange
    numbers <- c(1, 2)

    # Act
    result <- my_sum(numbers)

    # Assert
    expect_equal(result, 3)
  })
})

── Failure: my_sum: should calculate the sum for multiple numbers ──────────────
`result` not equal to 3.
target is NULL, current is numeric

Error:
! Test failed

We implement the function, with the interface we want to use.

Now we see a different test output, now it’s a failiure due to the function returning the incorrect value.

✅ Green

sum.R

my_sum <- function(x) {
  x[1] + x[2]
}

test-sum.R

describe("my_sum", {
  it("should calculate the sum for multiple numbers", {
    # Arrange
    numbers <- c(1, 2)

    # Act
    result <- my_sum(numbers)

    # Assert
    expect_equal(result, 3)
  })
})

Test passed 😀

To make the tests pass we can provide the simplest implementation. If this is the only usage of this function, this implementation would be completely sufficient.

❌ Red

sum.R

my_sum <- function(x) {
  x[1] + x[2]
}

test-sum.R

describe("my_sum", {
  it("should calculate the sum for multiple numbers", {
    # Arrange
    numbers <- c(1, 2)

    # Act
    result <- my_sum(numbers)

    # Assert
    expect_equal(result, 3)
  })

  it("should calculate the sum for one number", {
    # Arrange
    numbers <- c(1)

    # Act
    result <- my_sum(numbers)

    # Assert
    expect_equal(result, 1)
  })
})

Test passed 🎊
── Failure: my_sum: should calculate the sum for one number ────────────────────
`result` not equal to 1.
1/1 mismatches
[1] NA - 1 == NA

Error:
! Test failed

1. But we want it to work for more cases, not just adding two numbers together.

2. We add another case, we expect it to work with a single number. This implementation doesn’t do the job. We need to change it.

✅ Green

sum.R

my_sum <- function(x) {
  sum <- 0
  for (number in x) {
    sum <- sum + number
  }
  sum
}

test-sum.R

describe("my_sum", {
  it("should calculate the sum for multiple numbers", {
    # Arrange
    numbers <- c(1, 2)

    # Act
    result <- my_sum(numbers)

    # Assert
    expect_equal(result, 3)
  })

  it("should calculate the sum for one number", {
    # Arrange
    numbers <- c(1)

    # Act
    result <- my_sum(numbers)

    # Assert
    expect_equal(result, 1)
  })
})

Test passed 🎉
Test passed 🥳

This implementation does it’s job. Tests are green.

🔁 Refactor

sum.R

my_sum <- function(x) {
  base::sum(x)
}

test-sum.R

describe("my_sum", {
  it("should calculate the sum for multiple numbers", {
    # Arrange
    numbers <- c(1, 2)

    # Act
    result <- my_sum(numbers)

    # Assert
    expect_equal(result, 3)
  })

  it("should calculate the sum for one number", {
    # Arrange
    numbers <- c(1)

    # Act
    result <- my_sum(numbers)

    # Assert
    expect_equal(result, 1)
  })
})

Test passed 🎉
Test passed 🥳

Now can refactor the code to make it cleaner or more efficient.

😏 That was easy.

How do we use it for more complex problems?

2 approaches

📈 Bottom-up

📉 Top-down

2 approaches

📈 Bottom-up

Start small. 🧱

A design emerges. 🏛️

📉 Top-down

1. We start small, with the smallest piece of the problem we can solve.
2. We use existing pieces of codebase.
3. We don’t know upfront how the solution will look like. We let the design emerge from the tests and code that we write.

2 approaches

📈 Bottom-up

📉 Top-down

List high-level objectives first. 🎯

Describe behavior from user perspective. 🙌

Fill in the gaps until tests pass. 🧩

1. We focus on high-level objectives first.
2. We describe the behavior from the user perspective. If it’s a Shiny app, this is the perspective of the user interacting with the app. If it’s a package, this is a perspective of the user using the functions exported from the package.
3. We fill in the gaps in code, until tests pass.

So how do we choose the approach?

🏎️ We do what helps us move fast.

If we’re developing a Shiny module a list of user behaviors we want to implement can be more useful. We do top-down approach.

If we’re developing a computation of a complex algorithm, you might want to start from the smallest piece of the algorithm and build up from there. This would be bottom-up approach.

We do what helps us move fast.

🧪 Tests are the driving force.

They tell us if the code does what we think it does.

1. This is what Test-Driven means. Tests drive the development process.
2. They tell us what to do next and if the code we implemented does what we think it does.

From requirements to tests

🙋‍♀️ 💬

🙋‍♂️ 💬

➡️

✅ Pass

✅ Pass

So you probably have some requirements from your client that you need to implement. How do we get from there to tests?

• 👍 Examples help us understand the problem.
• 👎 Abstract descriptions don’t.

Use specific examples. Examples are translatable to tests. Examples help us understand the problem better.

Abstract descriptions don’t have these properties.

📝 Acceptance criteria

A list of verifiable statements.

• ☑️ Something should do something.
• ☑️ Something should do the other thing.

describe("something", {
  it("should do something", {
    # Arrange

    # Act

    # Assert
  })

  it("should do the other thing", {

  })
})

So how do we get these examples? 1. A common way of writing down requirements are acceptance criteria. They are a list of verifiable statements. 2. For example: something should do something. 3. Or it should also do the other thing when something else happens. They should be:

• Clear, so that everyone understands them.
• Concise, so that there’s no ambiguity.

1. See how easy it is to put those descriptions into a test file, then we can start filling those test.

📝 Test cases

🎯 Specific for low-level (unit) tests.

💬 Abstract for high-level (acceptance) tests.

Some tips of writing test cases.

📝 Test cases

🎯 Specific for low-level (unit) tests.

☑️ It should work correctly.

☑️ It should throw an error when the table has 1 row.

💬 Abstract for high-level (acceptance) tests.

1. They should be specific for low-level tests, when we have a specific input and output.
2. We should be specific for tests of business logic and edge cases.

📝 Test cases

🎯 Specific for low-level (unit) tests.

💬 Abstract for high-level (acceptance) tests.

☑️ It should render the table after clicking the “Go” button.

☑️ It should show the summary.

1. For high-level tests, as tests of Shiny modules it’s better to make them abstract, so that they will be true even if the implementation details change.

2. For tests of a Shiny module, don’t tie requirements to the UI. Focus on the business goal. Write those requirements such as if you’ve never heard about buttons, dropdowns or inputs.

This is the key to having test cases decoupled from implementation.

The example requirement would no longer be valid if we changed the label of the button, or if we removed the button altogether.

But the business goal would still be valid. It should show the summary, no matter how it can be achieved.

Tests show we solved the problem.

📝 And document what we solved.

So, this means that tests can show that we solved a problem. The will document it, and this documentation will be valid as long as the tests pass, compared to code comments or other documentation types which can get outdated anytime.

Drive communication with a client.

📊 Via executable examples on real data.

And this also means that we can use tests to communicate with our clients better. Tests can empower them to cooperate with us more closely. They can provide us examples which we can translate into tests. Tests are artifacts they can inspect and validate if that’s what they needed.

TDD x Shiny

• 📦 The testable unit of an app is a Shiny module.

• ✨ It represents a feature.

• 🖥️ It can be run as a standalone app.

So let’s see how we can use TDD with Shiny.

There are 3 things we need to know before we start.

1. The testable uning of a Shiny app is a Shiny module.
2. A module can represent a feature, and by feature I mean a part or the whole problem we’re solving with the app.
3. And that we can easily run modules as standalone Shiny apps.

Example

Let’s see in practice how the process looks like.

We’ll implement a module that shows a summary of a dataset.

❌ Red

dataset_summary.R

#

test-dataset_summary.R

describe("dataset summary", {
  it("should show the summary", {
    fail("Not implemented")
  })
})

── Failure: dataset summary: should show the summary ───────────────────────────
Not implemented

Error:
! Test failed

We start from an empty tests. Same as we did in the first example.

❌ Red

dataset_summary.R

#

test-dataset_summary.R

describe("dataset summary", {
  it("should show the summary", {
    # Arrange
    app <- shinyApp(
      ui = dataset_summary_ui(NULL),
      server = \(input, output) dataset_summary_server(NULL)
    )
    page <- DatasetSummary$new(app)

    # Act

    # Assert
    page$expect_summary_visible()
    fail("Not implemented")
  })
})

── Error: dataset summary: should show the summary ─────────────────────────────
Error in `dataset_summary_ui(NULL)`: could not find function "dataset_summary_ui"
Backtrace:
    ▆
 1. └─shiny::shinyApp(...)
 2.   └─shiny:::uiHttpHandler(ui, uiPattern)
 3.     └─base::force(ui)

Error:
! Test failed

1. We start from setting up the environment. We create a Shiny app from the nonexistent module.
2. Then we create an object that represents the module, it will be a proxy for communicating with the module. We will create it in next steps. For now our only focus is to imagine how we want to use it. We provide human-readable methods that will hide implementation details of the test. This will make tests easier to understand and maintain. Instead of using an object we could use functions. This doesn’t matter, do what feels more natural to you. The important part is that we’re abstracting the actions we can take on the module.
3. We don’t do anything in the execution part in this test. We test the default behavior, when no actions were taken, so it’s about the initial state of the module.
4. We assert that the summary is visible.

❌ Red

dataset_summary.R

dataset_summary_ui <- function(id) {
  fluidPage()
}

dataset_summary_server <- function(id) {
  moduleServer(id, function(input, output, session) {

  })
}

test-dataset_summary.R

describe("dataset summary", {
  it("should show the summary", {
    # Arrange
    app <- shinyApp(
      ui = dataset_summary_ui(NULL),
      server = function(input, output) dataset_summary_server(NULL)
    )
    page <- DatasetSummary$new(app)

    # Act

    # Assert
    page$expect_summary_visible()
    fail("Not implemented")
  })
})

── Error: dataset summary: should show the summary ─────────────────────────────
Error in `eval(code, test_env)`: object 'DatasetSummary' not found

Error:
! Test failed

When we provide the skeleton of the module, the test failure message changes. Now we need to implement the DatasetSummary object.

❌ Red

dataset_summary.R

dataset_summary_ui <- function(id) {
  fluidPage()
}

dataset_summary_server <- function(id) {
  moduleServer(id, function(input, output, session) {

  })
}

test-dataset_summary.R

DatasetSummary <- R6::R6Class(
  classname = "DatasetSummary",
  public = list(
    driver = NULL,
    initialize = function(app) {
      self$driver <- AppDriver$new(app)
    },
    expect_summary_visible = function() {

    }
  )
)

describe("dataset summary", {
  it("should show the summary", {
    # Arrange
    app <- shinyApp(
      ui = dataset_summary_ui(NULL),
      server = function(input, output) dataset_summary_server(NULL)
    )
    page <- DatasetSummary$new(app)

    # Act

    # Assert
    page$expect_summary_visible()
    fail("Not implemented")
  })
})

── Failure: dataset summary: should show the summary ───────────────────────────
Not implemented

Error:
! Test failed

This is where shinytest2 comes in handy. We can use it to interact with the app from within DatasetSummary methods. Wrapping shinytest2 calls in methods ensures that no implementation details are leaked into the test cases. Everything is contained within those methods.

❌ Red

dataset_summary.R

dataset_summary_ui <- function(id) {
  fluidPage()
}

dataset_summary_server <- function(id) {
  moduleServer(id, function(input, output, session) {

  })
}

test-dataset_summary.R

DatasetSummary <- R6::R6Class(
  classname = "DatasetSummary",
  public = list(
    driver = NULL,
    initialize = function(app) {
      self$driver <- AppDriver$new(app)
    },
    expect_summary_visible = function() {

    }
  )
)

describe("dataset summary", {
  it("should show the summary", {
    # Arrange
    app <- shinyApp(
      ui = dataset_summary_ui(NULL),
      server = function(input, output) {
        data_provider <- list(get_summary = \() {
          iris
        })
        dataset_summary_server(NULL, data_provider)
      }
    )
    page <- DatasetSummary$new(app)

    # Act

    # Assert
    page$expect_summary_visible()
    fail("Not implemented")
  })
})

── Failure: dataset summary: should show the summary ───────────────────────────
Not implemented

Error:
! Test failed

Now we may realize, that we need data to show the summary. We can provide it through a data provider object. This could be an existing object in the app, or if we’re starting a new app, this can be a fake object that represents a way of getting the data. This way we can test the module in isolation, without the access to the real data. What matters is the interface.

So this data provider just serves the iris dataset via it’s get_summary method. The module doesn’t know how the data is provided, it just needs to know how to get it. It could be from disk, from a database, it doesn’t matter here.

❌ Red

dataset_summary.R

dataset_summary_ui <- function(id) {
  fluidPage()
}

dataset_summary_server <- function(id, data_provider) {
  moduleServer(id, function(input, output, session) {

  })
}

test-dataset_summary.R

DatasetSummary <- R6::R6Class(
  classname = "DatasetSummary",
  public = list(
    driver = NULL,
    initialize = function(app) {
      self$driver <- AppDriver$new(app)
    },
    expect_summary_visible = function() {

    }
  )
)

describe("dataset summary", {
  it("should show the summary", {
    # Arrange
    app <- shinyApp(
      ui = dataset_summary_ui(NULL),
      server = function(input, output) {
        data_provider <- list(get_summary = \() {
          iris
        })
        dataset_summary_server(NULL, data_provider)
      }
    )
    page <- DatasetSummary$new(app)

    # Act

    # Assert
    page$expect_summary_visible()
    fail("Not implemented")
  })
})

── Failure: dataset summary: should show the summary ───────────────────────────
Not implemented

Error:
! Test failed

Here we’re evolving the interface of our module so that the data_provider can be passed to it. Notice how testing promotes dependency injection.

❌ Red

dataset_summary.R

dataset_summary_ui <- function(id) {
  fluidPage()
}

dataset_summary_server <- function(id, data_provider) {
  moduleServer(id, function(input, output, session) {

  })
}

🎯 {selenider}

test-dataset_summary.R

DatasetSummary <- R6::R6Class(
  classname = "DatasetSummary",
  public = list(
    driver = NULL,
    selenider = NULL,
    initialize = function(app) {
      self$driver <- AppDriver$new(app)
      self$selenider <- selenider_session(
        driver = self$driver,
        local = FALSE
      )
    },
    expect_summary_visible = function() {
      find_element(self$selenider, css = "#summary > table") |>
        elem_expect(is_visible) |>
        elem_expect(\(x) has_at_least(elem_children(x), 1))
    }
  )
)

describe("dataset summary", {
  it("should show the summary", {
    # Arrange
    app <- shinyApp(
      ui = dataset_summary_ui(NULL),
      server = function(input, output) {
        data_provider <- list(
          get_summary = function() {
            iris
          }
        )
        dataset_summary_server(NULL, data_provider)
      }
    )
    page <- DatasetSummary$new(app)

    # Act

    # Assert
    page$expect_summary_visible()
  })
})

── Failure: dataset summary: should show the summary ───────────────────────────
Condition failed:
`is_visible`
ℹ `x` is not visible.
Caused by error in `is_visible()`:
! `x` does not exist in the DOM.

Where `x` is:
A selenider element selecting:
The first element with css selector "#summary > table".


Backtrace:
     ▆
  1. ├─page$expect_summary_visible()
  2. │ └─selenider::elem_expect(...)
  3. │   └─selenider:::eval_conditions(x, dots, timeout)
  4. │     └─selenider:::eval_condition(x)
  5. │       ├─rlang::try_fetch(...)
  6. │       │ └─base::withCallingHandlers(...)
  7. │       ├─selenider:::with_timeout(0, eval_tidy(x, data = data_mask))
  8. │       │ └─base::force(code)
  9. │       └─rlang::eval_tidy(x, data = data_mask)
 10. └─selenider::elem_expect(...)

── Failure: dataset summary: should show the summary ───────────────────────────
Condition failed after waiting for 4 seconds:
`function(x) has_at_least(elem_children(x), 1)`
ℹ `x` does not exist, which may have caused the condition to fail.
Caused by error in `value[[3L]]()`:
! `x`'s parent element does not exist in the DOM.

Where `x` is:
A selenider element selecting:
The first element with css selector "#summary > table".


Backtrace:
    ▆
 1. └─page$expect_summary_visible()
 2.   └─selenider::elem_expect(...)

Error:
! Test failed

1. Next we can focus on the assertion.

I’m using functions from selenider package that provides a few nice assertions on an object derived from the AppDriver.

2. Think for a moment what outcome means that you met your objective.

In this case, asserting that the table is visible and that it has at least one row is a good way to ensure that the summary is shown.

Notice how this assertion is in a method. This way we can reuse it in other test cases. If at any point in time, our undestanding changes, we can change the implementation of this method, and all tests will be updated.

Pay attention to the name of the method. It’s abstract, it doesn’t mention the UI, that it’s a table. If we decide to show the summary as a plot, this would still be valid. It’s the same business goal, we don’t mention how it’s achieved.

✅ Green

dataset_summary.R

dataset_summary_ui <- function(id) {
  ns <- NS(id)
  fluidPage(
    tableOutput(ns("summary"))
  )
}

dataset_summary_server <- function(id, data_provider) {
  moduleServer(id, function(input, output, session) {
    output$summary <- renderTable({
      data_provider$get_summary()
    })
  })
}

test-dataset_summary.R

DatasetSummary <- R6::R6Class(
  classname = "DatasetSummary",
  public = list(
    driver = NULL,
    selenider = NULL,
    initialize = function(app) {
      self$driver <- AppDriver$new(app)
      self$selenider <- selenider_session(
        driver = self$driver,
        local = FALSE
      )
    },
    expect_summary_visible = function() {
      find_element(self$selenider, css = "#summary > table") |>
        elem_expect(is_visible) |>
        elem_expect(\(x) has_at_least(elem_children(x), 1))
    }
  )
)

describe("dataset summary", {
  it("should show the summary", {
    # Arrange
    app <- shinyApp(
      ui = dataset_summary_ui(NULL),
      server = function(input, output) {
        data_provider <- list(
          get_summary = function() {
            iris
          }
        )
        dataset_summary_server(NULL, data_provider)
      }
    )
    page <- DatasetSummary$new(app)

    # Act

    # Assert
    page$expect_summary_visible()
  })
})

Test passed 😸

Once we have the assertion in place, we can implement the module to satisfy the tests.

Notice how here we’re testing just the module with a fake data provider. The actual data provider object should be tested in isolation.

🔁 Refactor – UI 🖼️

dataset_summary.R

dataset_summary_ui <- function(id) {
  ns <- NS(id)
  fluidPage(
    tableOutput(ns("summary"))
  )
}

dataset_summary_server <- function(id, data_provider) {
  moduleServer(id, function(input, output, session) {
    output$summary <- renderTable({
      data_provider$get_summary()
    })
  })
}

test-dataset_summary.R

if (interactive()) {
  shinyApp(
    ui = dataset_summary_ui(NULL),
    server = function(input, output) {
      data_provider <- list(
        get_summary = function() {
          iris
        }
      )
      dataset_summary_server(NULL, data_provider)
    }
  )
}

DatasetSummary <- R6::R6Class(
  classname = "DatasetSummary",
  public = list(
    driver = NULL,
    selenider = NULL,
    initialize = function(app) {
      self$driver <- AppDriver$new(app)
      self$selenider <- selenider_session(
        driver = self$driver,
        local = FALSE
      )
    },
    expect_summary_visible = function() {
      find_element(self$selenider, css = "#summary > table") |>
        elem_expect(is_visible) |>
        elem_expect(\(x) has_at_least(elem_children(x), 1))
    }
  )
)

describe("dataset summary", {
  it("should show the summary", {
    # Arrange
    app <- shinyApp(
      ui = dataset_summary_ui(NULL),
      server = function(input, output) {
        data_provider <- list(
          get_summary = function() {
            iris
          }
        )
        dataset_summary_server(NULL, data_provider)
      }
    )
    page <- DatasetSummary$new(app)

    # Act

    # Assert
    page$expect_summary_visible()
  })
})

Test passed 🌈

By adding a call to a Shiny app in our test file, using the same setup as in the test, we can run it interactively.

1. 2. This way we can quickly iterate over the design and make the interface more usable and beautiful faster, without having to run the whole app.

We can also use this for manual exploratory testing or for interactive debugging. This test file is our entry point to the module.

Feature 👔

Feature 👔

Feature 👔

🧪 Unit tests

1. So we’ve developed one feature.
2. 3. 4. We can expand it with new specification.
3. 6. We can also add new features. Those are high-level tests of Shiny modules, that check if the business goal is achieved.
4. This is supplemented be regular, low-level unit testing that validate business logic.

We end up with tests for all building blocks of the app. We test and develop the parts separately. The sum of the parts is the whole app. This approach helps us maintain development speed, even as the app grows.

Why use TDD?

🏎️ Faster development cycles.

🧠 Understanding the problem.

🛡️ Confidence that it works.

So why should you give it a try?

1. To have faster development cycles, with clear feedback.
2. To understand the problem better. It will prevent you from solving something that you didn’t understand first.
3. To have confidence that what you’re developing is what you need. Also, to have confidence that if you change something, the rest doesn’t fall apart.

Thank you!

• linkedin.com/in/jakub-sobolewski-r/
• jakubsob.github.io/blog
• github.com/jakubsob/cucumber

Thank you for joining me today. If you want to read more about TDD or testing in general follow me on linkedin where I post when I write something new on the subject.

You can also check out my blog, where you can find all the content I’ve written so far.

And if you want to dive deeper into the world of high-level, top-down testing, check out my cucumber package. It might help you with developing your Shiny apps from the user perspective, especially when you have a lot of behaviors to implement.

Thank you once again :)