Skip to content
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

Use conditions for reporting results #360

Merged
merged 36 commits into from
Feb 19, 2016
Merged

Conversation

krlmlr
Copy link
Member

@krlmlr krlmlr commented Feb 5, 2016

Also: test_that() returns TRUE if successful (no failed expectations, errors, or skips) for programmatic use of testthat.

Bare expectations now simply stop if a test fails. The stop occurs upon the first event, unlike the StopReporter which stops after the first failed test.

@krlmlr krlmlr changed the title test_that() returns if tests passed test_that() returns TRUE if successful (no failed expectations, errors, or skips) Feb 5, 2016
class = c("test_result", "condition"))

withRestarts(
if (results$passed) signalCondition(cond) else stop(cond),
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could also call message() instead of signalCondition() here.

@krlmlr
Copy link
Member Author

krlmlr commented Feb 5, 2016

@hadley @jimhester: PTAL. Part of #215 (comment).

krlmlr pushed a commit to r-dbi/DBItest that referenced this pull request Feb 5, 2016
- Return test results as named array of logical. Requires r-lib/testthat#360.
krlmlr pushed a commit to r-dbi/DBItest that referenced this pull request Feb 6, 2016
- New tweak `union`, for specifying a nonstandard way of combining queries.
- All union queries now use full qualification for each column (required for `bigrquery`).
- Return test results as named array of logical. Requires r-lib/testthat#360.
- Use fork of `testthat`.
krlmlr pushed a commit to r-dbi/DBItest that referenced this pull request Feb 10, 2016

withRestarts(
{
signalCondition(cond)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Call stop() here.

@krlmlr krlmlr changed the title test_that() returns TRUE if successful (no failed expectations, errors, or skips) Use conditions for reporting results Feb 12, 2016
Kirill Müller added 2 commits February 12, 2016 09:56
Now a failing expectation always raises an error, even if the StopReporter isn't active. The update of this test reflects this change in behavior.
krlmlr pushed a commit to r-dbi/DBItest that referenced this pull request Feb 12, 2016
- New feature: tweaks
    - New argument `tweaks` to `make_context()` (#49).
    - New `tweaks()`, essentially constructs a named list of tweaks but with predefined and documented argument names.
    - `constructor_name`, respected by the `constructor.*` tests.
    - `strict_identifier`, if `TRUE` all identifier must be syntactic names even if quoted. The quoting test is now split, and a part is ignored conditional to this tweak. The `roundtrip_quotes` tests also respects this tweak.
    - `omit_blob_tests` for DBMS that don't have a BLOB data type.
    - `current_needs_parens` -- some SQL dialects (e.g., BigQuery) require parentheses for the functions `current_date`, `current_time` and `current_timestamp`.
    - `union`, for specifying a nonstandard way of combining queries. All union queries now name each column in each subquery (required for `bigrquery`).

- New tests
    - `dbGetInfo(Result)` (r-dbi/DBI#55).
    - `dbListFields()` (#26).
    - New "package_name" test in `test_getting_started()`.
- Improved tests
    - Stress test now installs package in temporary library (before loading `DBI`) using `R CMD INSTALL` before loading DBI (r-dbi/RSQLite#128, #48).
    - Row count is now tested for equality but not identity, so that backends can return a numeric value > 2^31 at their discretion.
    - Call `dbRemoveTable()` instead of issuing `DROP` requests, the latter might be unsupported.
    - Use subqueries in queries that use `WHERE`.
    - Test that `dbClearResult()` on a closed result set raises a warning.
    - Expect a warning instead of an error for double disconnect (#50).
    - Move connection test that requires `dbFetch()` to `test_result()`.
    - Split "can_connect_and_disconnect" test.
    - Expect `DBI` to be in `Imports`, not in `Depends`.
- Removed tests
    - Remove test for `dbGetException()` (r-dbi/DBI#51).
- Bug fixes
    - Fix broken tests for quoting.
- Self-testing
    - Test `RPostgres`, `RMySQL`, `RSQLite` and `RKazam` as part of the Travis-CI tests (#52).
    - Travis CI now installs rstats-db/DBI, updated namespace imports (`dbiCheckCompliance()`, `dbListResults()`).

    - Use fork of `testthat`.
- Utilities
    - Return test results as named array of logical. Requires r-lib/testthat#360, gracefully degrades with the CRAN version.
- Internal
    - Refactored the `get_info_()` tests to use a vector of names.
    - Use versioned dependency for DBI
    - Use unqualified calls to `dbBind()` again
- Same as 1.0-8.
@krlmlr krlmlr mentioned this pull request Feb 18, 2016
@@ -73,6 +82,28 @@ test_code <- function(description, code, env) {
invisible(ok)
}

report_results <- function(results) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this would be better called report_expectation(), but I'm not sure report() is quite the right verb (but I'm not sure what would be better)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or should this all be wrapped up into expectation()?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean that expectation() should create and raise the condition object? This means that we need to be very clever in expect_that(): Catch the condition (which is created in the condition(object) call), patch it, and re-raise it. To me, this looks like too much effort for too little gain. But I agree that expectation() should return a proper condition object right away. I'll update the PR soon.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should have expectation() (noun) to create the object, and expect() (verb) raise the condition?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We already have expect() which accepts a logical and a message; we'll need as.expectation.logical() and as.expectation.expectation() to avoid changing too much unrelated code, but otherwise this is doable. How does that sound?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then we'll add as.expectation.error(), as.expectation.skip() (as replacement for current expecation_error() and expectation_skipped()) and later as.expectation.warning() (#310).

@krlmlr
Copy link
Member Author

krlmlr commented Feb 19, 2016

Are you planning further refactorings? Then it would be great to merge this beforehand, otherwise I'll work further on this branch.

@hadley
Copy link
Member

hadley commented Feb 19, 2016

I don't have anything else major planned - I think most of the other issues need this PR completed first.

@krlmlr
Copy link
Member Author

krlmlr commented Feb 19, 2016

Extracted expectation_ok(), got rid of success_msg in my code, added two TODO markers.

I think test_code() can be simplified considerably, so that there's basically just one handler function taking care of everything. The reporter should be able to decide if tryCatch() catches the errors or not (#356) :

tryCatch(stop(), error = NULL)
tryCatch(stop(), error = function(e) NULL)

I'll merge the other PR before adding NEWS to this PR.

update_expectation(exp, srcref)
}

update_expectation <- function(exp, srcref, info = NULL, label = NULL) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It feels like we should be able to eventually eliminate this function, wrapping it into the constructor

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Difficult without finally deprecating info and label arguments (#218).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, lets look again once we've eliminated those args and refactored the expectations

@krlmlr
Copy link
Member Author

krlmlr commented Feb 19, 2016

Done. One more thing: expectation() is exported, you have changed its interface. Perhaps it's safer to keep success_msg (with a warning), or introduce a ... .

@hadley
Copy link
Member

hadley commented Feb 19, 2016

Yeah, I'm not too worried about that. I think the next release will be testthat 1.0.0 so it's ok to make a few breaking changes (and I doubt this one will affect many people)

@hadley
Copy link
Member

hadley commented Feb 19, 2016

And looks good to merge - feel free whenever you think it's ready

krlmlr added a commit that referenced this pull request Feb 19, 2016
* Refactored internal testing logic. Now all expectations are also conditions, and R's condition system is used to signal failures and successes (#360, @krlmlr).

* `test_that()` returns a `logical` that indicates if all tests were successful (#360, @krlmlr).
@krlmlr krlmlr merged commit 0719724 into r-lib:master Feb 19, 2016
@krlmlr krlmlr deleted the feature/return-value branch February 19, 2016 10:39
@krlmlr krlmlr mentioned this pull request May 7, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants