Conversation
| describe 'Factory' do | ||
| it 'has a valid factory' do | ||
| # Testear que el factory definido es válido. | ||
| expect(FactoryBot.create(:post)).to be_valid |
There was a problem hiding this comment.
Podemos aprovechar una configuración que agregamos en spec/rails_helper.rb por la cual no hace falta agregar el FactoryBot. a estos métodos.
La línea en cuestión es la siguiente:
config.include FactoryBot::Syntax::MethodsAdemás, pese a que el test pasa y está bien, podemos usar un build para no persistir al Post en la base de datos (para mejorar la performance). De todas formas, el build persiste aquellas asociaciones que tenga definido el factory, por lo cual podemos usar uno mejor: build_stubbed. En la próxima clase lo vemos.
expect(build_stubbed(:post)).to be_valid| describe 'Uniqueness validations' do | ||
| # Testear validaciones de unicidad (shoulda-matchers). | ||
| # https://github.com/thoughtbot/shoulda-matchers#activemodel-matchers | ||
| let!(:subject) { FactoryBot.create(:post) } |
There was a problem hiding this comment.
Alternativamente podemos usar subject:
subject { create(:post) }| describe 'Factory' do | ||
| it 'has a valid factory' do | ||
| # Testear que el factory definido es válido. | ||
| expect(FactoryBot.create(:user)).to be_valid |
There was a problem hiding this comment.
Misma consideración para el test de factory del modelo Post. Igualmente está bien.
| describe 'Uniqueness validations' do | ||
| # Testear validaciones de unicidad (shoulda-matchers). | ||
| # https://github.com/thoughtbot/shoulda-matchers#activemodel-matchers | ||
| let!(:subject) { FactoryBot.create(:user) } |
There was a problem hiding this comment.
Misma consideración para el test similar del modelo Post. Igualmente está bien.
| # - 'when given value is different from password' | ||
| # - 'when given value is equal to password' | ||
| context 'when given value is different from password' do | ||
| let!(:subject) { FactoryBot.create(:user, password: 'password') } |
There was a problem hiding this comment.
Tanto para este caso como para el del siguiente context, creo que en lugar de hacer let!(:subject) haría subject directamente. De todas formas el uso de let! también está bien.
Podría ser de la siguiente forma:
context 'when given value is different from password' do
subject { create(:user, password: 'password') }
...
end|
|
||
| it 'returns false' do | ||
| skip 'Implementar' | ||
| expect(subject.call).to eq(false) |
There was a problem hiding this comment.
En el ejemplo de arriba el subject es la aplicación de call sobre la instancia, mientras que en éste es la instancia, y luego le mandás el mensaje call en el it. Ambas están bien, pero sería preferente usar una convención.
No description provided.