discuss tradeoffs of mocking and faking

[maxheld83]

trafficstars

closes #90

[maxheld83]

btw, I love that you guys are hard-wrapping by sentence in the rmd ☺️. Been trying to lobby the tidyverse to adopt that elsewhere: https://github.com/tidyverse/style/issues/162

[maxheld83]

Great + agreed! I'll work in those suggestions @maelle -- could be a day or two.

[maelle]

thanks, no hurry!

[maelle]

I was just thinking about proper attribution of work @maxheld83

• Please add a sentence to the beginning of the chapter you'll add, mentioning it was contributed by you.
• Add a sentence just before https://github.com/ropensci-books/http-testing/blob/13996fbfeabde2975acb054249106608931bf898/index.Rmd#L31 (we'll now start listing contributor as in https://devguide.ropensci.org/preface.html)

[maxheld83]

yikes, sorry I took so long to follow up:

I like the content but feel it should come later in the book are things are complicated enough at this stage. Maybe a compromise would be to have a sentence in the intro (or conclusion of the Whole Games section) in a very small section "Can one use packages for HTTP testing as little as possible?" or so and have a link to a chapter later in the book, that'd feature this current content (in advanced topics).

• [x] The discussion now lives in its own chapter, with a short pointer in the beginning.

In your own packages, are there examples of code or tests that you could permalink and comment to help make things less theoretical? Or even false code? E.g. when you write "other functions", you could explain what those do e.g. data munging, what the functions interacting with the API return, to help readers visualize things a bit more?

• [x] I've added an example of how to minimise / tradeoff mocking/faking from a real-life package (http://subugoe.github.io/biblids/). I've simplified the code a bit, but it works.

• [x] added attribution as requested.

[maxheld83]

thanks so much for taking the time to so carefully review this again @maelle!

I've fixed some of the smaller things and changed the chapter location.

But I'm not sure about the overall tone and direction.

I appreciate that the book is trying to be very hands-on and welcoming, but I think my concern here is/was indeed that there's a very real danger to jump into the tools before carefully thinking through the concepts. I prefer to first worry about the concepts (the purpose of TDD in this case?), and then jump into the tooling. I don't have any formal training, and I think I've in the past often excitedly jumped onto new tools and built myself into a crazy complicated corner.

I also personally find opinionated heuristics ("strong opinions weakly held") helpful, though that's a matter of style. (And I may just be wrong).

I wonder whether this chapter actually fits into the book, because of these (potential) differences. This is your show after all, and a book should speak with one voice/tone, so I'd be happy to move this over to biblids or a blog, and then perhaps a short link to that can point people to it, if they're curious.

Let me know how you feel.

[maelle]

Thank you! Maybe you could publish it as a blog post first, and then, once you've received a bit of feedback, come back to adding it as a chapter here if you so wish? :thinking:

[maelle]

(I'll be happy to link to the blog post in any case, as again, this is important :-) )

[maxheld83]

Thank you! Maybe you could publish it as a blog post first, and then, once you've received a bit of feedback, come back to adding it as a chapter here if you so wish

That's a great idea. I'll let this linger as a "draft" then until there's some feedback on another venue.

[maelle]

Closing for lack of recent activity (but please ping me if you wrote a blog post, and thanks a lot for contributing!)