Skip to content

Adds specs for ApiLoginManager, User model and Post model - #1

Open
Crentist wants to merge 1 commit into
lucashour:masterfrom
Crentist:master
Open

Crentist wants to merge 1 commit into
lucashour:masterfrom
Crentist:master

Conversation

@Crentist

Copy link
Copy Markdown

No description provided.

@Crentist Crentist changed the title Added specs for ApiLoginManager, User model and Post model Adds specs for ApiLoginManager, User model and Post model May 24, 2019

@lucashour lucashour left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Listo el review, no es necesario modificar.

Comment thread spec/models/post_spec.rb
describe 'Factory' do
it 'has a valid factory' do
# Testear que el factory definido es válido.
expect(FactoryBot.create(:post)).to be_valid

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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::Methods

Ademá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

Comment thread spec/models/post_spec.rb
describe 'Uniqueness validations' do
# Testear validaciones de unicidad (shoulda-matchers).
# https://github.com/thoughtbot/shoulda-matchers#activemodel-matchers
let!(:subject) { FactoryBot.create(:post) }

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternativamente podemos usar subject:

subject { create(:post) }

Comment thread spec/models/user_spec.rb
describe 'Factory' do
it 'has a valid factory' do
# Testear que el factory definido es válido.
expect(FactoryBot.create(:user)).to be_valid

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Misma consideración para el test de factory del modelo Post. Igualmente está bien.

Comment thread spec/models/user_spec.rb
describe 'Uniqueness validations' do
# Testear validaciones de unicidad (shoulda-matchers).
# https://github.com/thoughtbot/shoulda-matchers#activemodel-matchers
let!(:subject) { FactoryBot.create(:user) }

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Misma consideración para el test similar del modelo Post. Igualmente está bien.

Comment thread spec/models/user_spec.rb
# - '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') }

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants