I had thought did_you_mean for KeyErrors was available in Ruby 2.3 and
higher, but this spec seems to be failing for Ruby 2.3 and 2.4.
Since we have OK coverage of the custom KeyError message behavior
elsewhere, I don't think this test is essential.
to make use of did_you_mean gem.
The did_you_mean gem only supports NameError, NoMethodError
and KeyError. However, for NameError the message does also need
to match a certain format and we can not use a custom message
like 'Factory not registered ...'. Therefore using KeyError
is to only logical conclusion.
The did_you_mean gem makes use of the receiver attributes, but
in Ruby > 2.5 it is not possible to set the receiver and key attributes
on a KeyError (they are only set when the KeyError is raised in C).
We explored monkey patching KeyError for earlier versions of Ruby, but
it was a problematic solution.
Instead we can rescue the original KeyError, take the message from it,
which will already include the did_you_mean message, then customize
the message and re-raise a new KeyError with that customized message.
Starting in Ruby 2.6 this will not be necessary anymore
https://bugs.ruby-lang.org/issues/14313, so maybe we can get rid of it
for FactoryBot 6 or 7.
Fixes#992
Co-authored-by: Daniel Colson <danieljamescolson@gmail.com>
This spec was introduced back in 18c562a1e6, at which point it was
testing that the to_create block got passed to a proxy object.
A lot has changed since then, and this test is no longer testing
anything involving to_create (we can remove the call to to_create and it
still passes). It is testing that we instantiate a strategy and pass an
evaluation to it, but that isn't a helpful test. The behavior we
actually care about is well tested in acceptance specs.
Closes#970
In this code we are passing an implicit declaration `user`, rather than
the symbol `:user`:
```rb
factory :post do
author factory: user
end
```
This will raise a confusing error:
`undefined method 'name' for :comment:Symbol`.
This is coming from the implicit declaration `#==` method,
called on lib/factory_bot/attribute_list.rb#56.
The method wasn't ever designed to compare against
objects of different classes. I added some tests for all the declaration
classes to handle being compared against other kinds of objects.
Co-authored-by: Dusan Orlovic <duleorlovic@gmail.com>
Closes#1033
> Arguably, association should raise and let the developer know
> they're using it in an unexpected way. I'd love to see a PR for
> that (with a test!), so if you're interested in contributing that,
> please do!
> https://github.com/thoughtbot/factory_girl/issues/1032#issuecomment-329297006
Co-authored-by: Daniel Colson <danieljamescolson@gmail.com>
Fixes 1155
Defining an attribute called 'attributes', then referring to that
attribute in `initialize_with` was causing `AttributeHash#attributes`
to call itself recursively.
Closes#1202
We have fixed the bulk of the RuboCop TODOs. The main TODO remaining
(line length) involves a large number of files,
and I don't think it is worth trying to update them all at once. I did
fix a few of the worst offenders so we could bring the max down a bit.
We can gradually bring this number down as we fix more of the
violations.
This warning made sense when we had static attributes, since
somebody might try to write something like:
```rb
factory :composer do
self.name = "Daniel"
end
```
That would create a static declaration when the factory was defined,
then raise the error about avoiding writers when the factory was run.
Now this code will raise a NoMethodError right away when the factory is
being defined.
Inside `super` Ruby calls `inspect`, but since we have undefined
`inspect` on the definition proxy we end up declaring an implicit
`inspect` attribute. We do the same thing with `methods` and
`singleton_methods`, and then `inspect` again. By the time we finally
see the NoMethodError, we see it on a
`FactoryBot::Declaration::Implicit` instead of the definition proxy.
By raising the NoMethodError manually we avoid this nonsense and have
the added benefit of showing the name of the factory where the missing
method came from.
* Alphabetize gem listing in various Gemfiles [Rubocop Bundler/OrderedGems]
* Fix alignment of if/else/end statement [Rubocop Layout/ElseAlignment]
* Method definitions should have a empty line between them [Rubocop Layout/EmptyLineBetweenDefs]
* Modules, Classes, and blocks should have an empty line around them [Rubocop]
Cops:
Layout/EmptyLinesAroundBlockBody
Layout/EmptyLinesAroundModuleBody
Layout/EmptyLinesAroundClassBody
Layout/EmptyLinesAroundAccessModifier
* Keep a blank line before and after access modifiers [Rubocop Layout/EmptyLinesAroundAccessModifier]
* Remove misc extra whitespace [Rubocop Layout/ExtraSpacing]
* Indent the first line of the right-hand-side of a multi-line assignment [Rubocop Layout/IndentAssignment]
* Remove extraneous whitespace [Rubocop]
Cops:
Layout/IndentationWidth
Layout/LeadingCommentSpace
Layout/SpaceAroundEqualsInParameterDefault
Layout/SpaceInsideArrayLiteralBrackets
Layout/SpaceInsideBlockBraces
Layout/SpaceInsideParens
Layout/TrailingBlankLines
* Revert rubocop changes to gemfiles; exclude files from rubocop checks
The files in gemfiles/ are generated by Appraisal, so we shouldn't edit them. Instead, let's tell RuboCop to exclude this directory.
to run rubocop locally and not to wait for HoundCI to bark at us.
The version is locked to 0.54 because this is the version HoundCI is using.
Using a newer version will not work as config changed from 0.54 to currently 0.59
and rubocop would complain with the old configuration.
thoughtbot uses the .rubocop.yml in thoughtbot/guides
as the orginizational config on Hound, so we inherit
from it so we can use the same config locally.
Fix#1195.
This changes the signature of `add_attribute`, so if you pass a value at
all you will now get an `ArgumentError`. Any `method_missing`-style
static attribute definitions will become `NoMethodError`s.
This was originally opened as #1078, but this addresses the review
comments on that PR.
By registering the inline sequences, we allow them to get rewound with
`FactoryBot.rewind_sequences`. We register them with
`__#{factory_name}_#{sequence_name}__` to avoid conflicting with any
reasonably named global sequences, and to hint that we should not be
generating values from these sequences directly.
Co-authored-by: Damian Le Nouaille <dam@dln.name>
Co-authored-by: Damian Galarza <galarza.d@gmail.com>
decrement, increment, and toggle do not persist the toggled values, so
there is not reason to disable those methods.
Co-authored-by: Alex Tsui <alextsui05@gmail.com>
Daniel Colson