-
Notifications
You must be signed in to change notification settings - Fork 5
Ensure that API and SQL queries return identical results #421
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
base: v2.3.1
Are you sure you want to change the base?
Conversation
|
tests fail on windows, no real output message. This might be present on v2.3.1, something to look into. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR introduces comprehensive protocol-agnostic testing to ensure that API and SQL database queries return identical results. The implementation adds a test framework that compares function outputs when using either the OpenCPU API or local database connections, helping maintain data consistency across different access methods.
- Added a new test file with 15 test cases covering listing functions and acoustic detection queries
- Created a reusable expectation function that mocks protocol selection to test both API and database paths
- Tests are designed to run only on machines with local database access, skipping automatically on CI
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| tests/testthat/test-protocol_agnostic.R | Implements comprehensive test cases for protocol-agnostic behavior of listing functions and acoustic detection queries |
| tests/testthat/helper-expectations.R | Creates the expect_protocol_agnostic() helper function that mocks protocol selection to compare API vs database results |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
Co-authored-by: Copilot <[email protected]>
….com/inbo/etn into custom-expectation-api_sql-identical
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## v2.3.1 #421 +/- ##
==========================================
+ Coverage 84.55% 84.68% +0.13%
==========================================
Files 26 26
Lines 725 725
==========================================
+ Hits 613 614 +1
+ Misses 112 111 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
|
TODO:
Because all these queries are live, both over the api and the database (they have to be, or I'd have to mock all database returns, and then the test is kind of mute), this puts a lot of load on the API.Perhaps these tests should only run on a single runner? Or only every so often?Maybe they should run regardless of changes in the package, on a schedule instead?These tests will only ever run on a machine with local database access, and thus can only be tested on the RStudio server. It will always be skipped on CI.
Blocked by I've lost access to the new RStudio Server #423
get_acoustic_detections(): create viadatapackage.json? Some booleans are returned as characters over the API (entirely empty)datapackage.jsoninstead of trying to work with R -> Arrow Schema -> R ?test failures
Vector order
Seems to be related to the order in which it is returned. Strange that this differs! Switch
etnservicetostringinatural sorting to avoid OS differences?Functions that call
stringr::str_sort(data$serial_number, numeric = TRUE)inetnservicedo pass. That must be it.Boleans as strings
Some fields are interpreted as character, while they are logical. This happens over the API only, it's happening in the OpenCPU layer of the protocol.