Thank you very much for your contribution.
- It is a nice piece of work, although at first I'd like to give suggestions on putting more description on your commit messages and split your changes over several commits. Creating a feature branch then merge it to your master branch, which will make your commit history a bit more oraganised and clean.
- Nice to see that you have unit tests - and I am curious to know that will this test be too fragile? if the balance changes somehow?
- You probably can fork your http object and test more functionalities of your
Stream
class.
Your contribution has been evaluated according to Utopian policies and guidelines, as well as a predefined set of questions pertaining to the category.
To view those questions and the relevant answers related to your post, click here.
Need help? Chat with us on Discord.
Short answer: yes, with an "if." Long answer: no, with a "but."
The tests are wrapped in a
vcr_cassette
closure that records the first request to a.yml
file. Subsequent test runs will not be affected by real-world changes on the side-chain until the.yml
file is deleted. I have a task calledrake clean:vcr
that deletes all of these.yml
files, which I use for picking up real-world changes. In that situation, yes, this test would break.This approach means Continuous Integrations won't break, which is all I want. Typically, I only delete the
.yml
files as a last step. I actually recommend some fragile tests like this to help test around null hypothesis assumptions.Good point about the
Stream
class. Thanks for the suggestions.Thank you for your review, @justyy! Keep up the good work!