Identify Uncovered Code Parts: The covr package generates a coverage report. This report will show which parts of your code are not currently covered by the tests. The goal is to aim for a high percentage of code coverage. This is not to say that 100% coverage is necessary or always beneficial, but a higher coverage percentage can often lead to fewer undetected bugs.
Design and Add New Tests:
For every part of the code that isn't covered by tests, think about its expected behaviour. This includes the expected outputs for given inputs and whether they should throw errors or warnings under certain conditions. Write new tests that check for these things.
Don't forget to test boundary conditions and edge cases. In these situations, the input is at the end of what's valid, like a list with zero elements or a string with maximum length. These edge cases are often overlooked in testing but can often cause bugs.
Consider also unusual or invalid inputs. The code should handle these gracefully by rejecting them with a clear error message or by handling them in a way that makes sense in context. Tests for these cases help ensure that the code is robust.
Use Appropriate Testing Functions: The testthat package provides a range of functions for testing different conditions. Choose the function that best matches what to test. For example, expect_equal() checks if two values are equal, expect_error() checks if a piece of code throws an error, and expect_warning() checks if it throws a warning.
Organize Tests Clearly:
Use the context() function to group related tests. This can make it easier to understand what each test is for and how the tests relate.
Within each context, use the test_that() function to define each test. The first argument to test_that() is a descriptive string that explains what the test is checking. This makes the tests self-documenting: someone reading the test code can understand what each test is for just by reading these descriptions.
Refactor Tests When Necessary: Adding more tests may make some of your tests repetitive or could be grouped more logically. In these cases, don't be afraid to refactor your tests. This could mean rewriting, reorganizing, or even deleting tests. The goal is to make the tests as clear, concise, and comprehensive as possible.
Continuous Review and Expansion: Expanding test coverage is not a one-time task but a continuous process. Reviewing the test coverage helps identify any gaps that arise over time. While adding or modifying features in your package, new tests should be added to cover the changes.
expect_equal()checks if two values are equal,expect_error()checks if a piece of code throws an error, andexpect_warning()checks if it throws a warning.context()function to group related tests. This can make it easier to understand what each test is for and how the tests relate.test_that()function to define each test. The first argument totest_that()is a descriptive string that explains what the test is checking. This makes the tests self-documenting: someone reading the test code can understand what each test is for just by reading these descriptions.