Carriles db prueba no persiste cambios de registros
-
23-09-2019 - |
Pregunta
he estado tratando de resolver un problema para algunas semanas. Me postulo pruebas rspec para mi aplicación Rails, y están trabajando bien, excepto por un error que parece que no puedo sacarlo de mi cabeza.
- Estoy utilizando MySQL con el motor InnoDB.
- he puesto en
config.use_transactional_fixtures = true
spec_helper.rb - cargo mis accesorios de prueba manualmente con el comando
rake spec:db:fixtures:load
. - La prueba rspec está siendo escrito para un trabajador BackgrounDRb, y se está probando que puede haber un registro actualizado su estado (a través de la gema state_machine).
Aquí está mi problema:
Tengo un modelo llamado Listings
. La prueba rspec llama al método update_sold_items
dentro de un archivo llamado listing_worker.rb
.
Este método llama listing.sell
para un registro determinado, que establece el récord lista de 'estado' a la columna 'vendido'.
Hasta ahora, todo esto está bien de trabajo, pero cuando los acabados método update_sold_items
, mi prueba rspec falla aquí:
listing = Listing.find_by_listing_id(listing_id)
listing.state.should == "sold"
expected: "sold",
got: "current" (using ==)
he estado tratando de localizar a por qué el cambio de estado no está persistiendo, pero estoy bastante perdido. Este es el resultado de un cierto código de depuración que coloqué en el método update_sold_items
durante la prueba:
pp listing.state # => "current"
listing.sell!
listing.save!
pp listing.state # => "sold"
listing.reload
pp listing.state # => "current"
No se puede entender por qué se ahorra perfectamente bien, pero luego vuelve de nuevo al registro original siempre que llame reload
o Listing.find
etc.
Gracias por leer esto, y por favor cualquier pregunta si no he dado suficiente información.
Gracias por su ayuda, Nathan B
P.S. No tengo un problema al crear nuevos registros para otras clases, y los ensayos de los registros. Sólo parece ser un problema cuando estoy actualizando los registros que ya existen en la base de datos.
Solución
sospecho, como Nathan, ediciones de la transacción. Trate de poner un Listing.connection.execute ( "COMMIT") justo antes de su primer salvamento llamada a romper la transacción y ver qué cambios. Que se romperá a salir de la transacción para cualquier llamada de reversión adicionales serán no eficaz.
Además, mediante la ejecución de un comando "COMMIT", se podría hacer una pausa en la prueba con un depurador e inspeccionar la base de datos de otro cliente para ver lo que está pasando.
La otra hipótesis, si la experimentación transacción no dió ningún resultado, es que tal vez su modelo realmente no está ahorrando a la base de datos. Revisar sus registros de consultas. (Específicamente encontrar la consulta de actualización).
Este tipo de cuestiones realmente apesta! ¡Buena suerte!
Otros consejos
Si desea investigar lo que tiene en el PP durante la ejecución de pruebas que puede encontrar útil esta información ...
Tengo una prueba rspec donde guardar @ user.save y funciona como un encanto, pero entonces yo quería ver si realmente guarda en la base de datos.
Me abrió la consola carriles para el entorno de prueba
rails c test
RAN
User.all
y como se esperaba nada tiene
Me pasé la especificación que contiene:
user_attr_hash = FactoryGirl.attributes_for(:user)
@user = User.new user_attr_hash
@user.save
binding.pry
pensé que detener la prueba después de guardar significaría que se persistió, pero ese no es el caso. Parece que el COMMIT se dispara la conexión más tarde (no tengo ni idea cuando: \) Por lo tanto, como sugiere @Tim Harper, usted tiene que fuego que cometen a sí mismo en la consola de palanca:
pry(#<RSpec::Core::ExampleGroup::Nested_1>)> User.connection.execute("COMMIT")
Ahora, si ejecuta User.all en sus rieles consola que merece la pena verlo;)