| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
Disable Metrics/BlockLength in specs because the length of a block in
the test suite isn't something we want to lint. We want the tests to be
as long as they need to be.
Set an explicit line length metric instead of continually updating this
as we go. Let's pick a max line length that we want to see and stick
with it. This metric should only ever decrease: we don't want to see it
ever increase again.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a big step forward in our Rubocop setup. I addressed all of the todos
from the current version of Rubocop that made sense to. The only things that
remain are metrics and one cop that relies on the line length metric to work.
I made some judgment calls on disabling a few cops:
1. The `Layout/IndentHeredoc` cop wants you to either use the squiggly heredoc
from Ruby 2.3 or introduce a library. Since we are a low-level library that
is used as a transitive dependency, we cannot introduce another library as a
dependence, so that option is out. Also, we support Rubies back to 2.0
currently, so using the squiggly heredoc isn't an option. Once we remove
support for Rubies older than 2.3, we can switch to the squiggly heredoc cop.
2. The `Naming/FileName` cop was reporting false positives for a few files in
the repository, so I disabled it on those files.
3. The `Style/DoubleNegation` cop reports lints on a few cases where we use
double negation. Given the very generic nature of Hashie, the double-negation
is the easiest, clearest way to express that we want an item to be a Boolean.
I disabled the cop because we exist in the gray area where this makes sense.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The documentation about the MethodQuery module spells out the expected
behavior. While the spec suite appeared to be testing the same, the
RSpec matchers were not actually checking the behavior properly. This
lead to a divergence between the expected behavior, as outlined in the
module documentation, and the actual behavior, as tested in the spec
suite.
This is the reason that #299 is happening: the expected behavior is not
the actual behavior. I have included a test for #299 to show that it
works as expected in this branch.
This change makes the spec suite match the behavior in the module
documentation, then modifies the methods to match the documentated
specification.
Lastly, I took the time to clean up the MethodQuery module for two
reasons:
1. The old implementation used Regexps on the stringified
method names, which is unnecessary since we have the wonderful
`String#end_with?` method to check the suffix of a strings.
2. The old logic was difficult to reason through, so I clarified the
intent of the methods by reducing the complexity of the conditionals
and extracting meaningful methods where possible.
|
| | |
|
| |
|
|
| |
This is part 2 of 3 of the to-do list determined in #198.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This conversion is done by Transpec 1.10.4 with the following command:
transpec
* 278 conversions
from: obj.should
to: expect(obj).to
* 32 conversions
from: obj.should_not
to: expect(obj).not_to
* 14 conversions
from: lambda { }.should
to: expect { }.to
* 3 conversions
from: its(:attr) { }
to: describe '#attr' do subject { super().attr }; it { } end
* 3 conversions
from: lambda { }.should_not
to: expect { }.not_to
* 1 conversion
from: obj.stub!(:message)
to: allow(obj).to receive(:message)
* 1 conversion
from: obj.should_receive(:message)
to: expect(obj).to receive(:message)
|
| | |
|
| | |
|
| | |
|
|
|
extension.
|
