-
Notifications
You must be signed in to change notification settings - Fork 1
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
start using webfakes #4
base: main
Are you sure you want to change the base?
Conversation
app <- presser::new_app() | ||
app$get("/", function(req, res) { | ||
res$send_json( | ||
list( components = |
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.
in this case I wrote the object to be returned by hand. This way my PR shows two methods (in one test the response is written in the test file, in the other case there's a JSON file that's loaded)
👋 @gaborcsardi, any comment on the approach? I might also add inst/real-tests and some Rbuildignore gymnastics in a scheduled workflow (to test real requests), as I did for httptest. |
I'll just need a day or so to get back into thinking about presser setup. |
no hurry, thanks |
I think this is all good. One thing to consider is whether you want to create an app that is reused in multiple test files. Either in |
I make this point in the chapter actually, I hope it'd be enough? What would be nice in the chapter actually is linking to a real-life PR, e.g. when/if you add presser tests to gh. |
Notes.
I created a JSON file by saving locally what I got in the browser. I could also have copy-pasted from the API docs. A developer would be expected to find their own workflows for creating fixtures, right?
With such a testing framework how do you check the API output didn't change? I can only think of scripting the fixture creation + looking at the git diff. And obviously, there's the indirect solution of running tests with real requests regularly.