My Rails console session went wrong and now my rspec tests fail? - ruby-on-rails

I am using Postgres 9.1, Rails 3.1.3 and Ruby 1.9.3.
I tried some things out in rails console --sandbox and then I ventured to rails console.
On entering Employee.create!(a whole lot of data), I got some errors, most of them to do with not null constraints.
I quickly left the console and using pgadmin3 checked to see if I had changed the database but there was no data so I felt confident that my tests would still pass. Unfortunately, my rspec test now fails and I am not sure where the conflicting data is.
Hopefully someone reading this has an idea or suggestion of how I can undo the entry I entered in my console session, which unfortunately was not the --sandbox session.
I did manage to kill the phantom server which I found through lsof | grep 3000.
Thanks for any help, suggestions or pointers you can spare.

When you play in the console, you're in the development environment, I don't think there is a way that it conflicts with your tests which are run in the test env.
Plus, the tests should not rely on any existant data, since the test database is erased each time you run your tests.
Try to run rake db:test:prepare and run your tests.

Related

"heroku run rails db:seed" stops without finishing ("State changed from up to complete")

I'm using Rails 6.0.2.2 with PostgreSQL 12.1. I've been trying to deploy my Rails app on Heroku, but when I run "heroku run rails db:seed", the seeding process stops without completing. If I check the logs, all it says is:
2020-04-19T04:47:10.789255+00:00 heroku[run.1139]: State changed from up to complete
But it never finished running the seed file. By adding print statements in the seed file, I can see that it always stops at the same place, where it's inserting (fairly large) amounts of data into the database. However, I don't see an out-of-memory or other error anywhere.
What might be the problem, or where can I find more information about what might be causing the problem?

Disconnect the database in Ruby on Rails

I have a Ruby on Rails data mining app, and I would like to be able to do powerful demonstrations without a complicated user-interface.
Is there any way I can make a ruby console for the web that doesn't run the risk of say...
User.destroy_all
?
Something where I can call
ActiveRecord.disconnect!
unsafe_actions
ActiveRecord.connect!
But where I could also have read priviledges (select, inner join, etc.)
Thanks,
Brian
You can run the rails console in sandbox mode:
rails console --sandbox
or
rails c -s
Any changes you make in sandbox mode will be rolled back upon exiting the console.
(And prefix with heroku run to run it on heroku.)

Rails Connecting to database specified by database.yml

I recently restarted POW. On reloading the Rails app I'm working on, it hung.
Checking Rails' logs I get the following repeating every 5-20 seconds:
Connecting to database specified by database.yml
I can interact with the Postgres db without issue through the Rails console, so there is no problem there. I haven't changed anything in my database.yml for weeks, so I don't think the problem is there.
What might be the problem and how can I debug it?
Turns out it was caused by POW
I had set '$powder always_restart` which was causing some sort of loop.
I reset this using `$ powder no_restarts'
Change your production database temporary to your development settings.
Then run in your terminal:
rails console production
Most of the times it is not about your database, but probably a syntax error. Anyways you can debug it like this.

Problem using `rake test`

I wonder how to setup testing in my rails apps. When I run rake test, first thing odd, it launch a bunch of CREATE TABLE against my dev. database (hum.. do not like this..). So I launch rake test RAILS_ENV=test and I even try bundle exec rake test RAILS_ENV=test. Now, the CREATE TABLE is against my test database but all fails with this error :
** Execute test:units
test/unit/category_test.rb:5:in `test': unknown command 't' (ArgumentError)
from test/unit/category_test.rb:5:in `<class:CategoryTest>'
I have used basic generator in Rails 3 and do not change anything. So I have this in caterogy_test.rb :
require 'test_helper'
class CategoryTest < ActiveSupport::TestCase
# Replace this with your real tests.
test "the truth" do
assert true
end
end
I use Rails 3.0.7 and basic config.
Any ideas ?
EDIT
I am becoming crazy, made a lot of tries, neither seems to work. When I start a new application with a few things, rake test works fine but when I try this on my current one, it launch always against my dev. db and do not work at all. I have tried to edit the test files, to revert them back, try to remove/setup test db with different ways, try different rake version, compare a lot of things on one side my current application and on the other a brand new one... Found nothing.. Help !
EDIT 2
Sounds lame, but is it normal that rake does the same thing than rake test ?
EDIT 3
Sounds odds, while I continue to work on what's wrong, I realize that every-time I run rake test, it does stuff on the dev environment and not the test one (watching the logs). It does this on my computer OSX and on our server FreeBSD for all the Rails 3.0.7 apps. Are you sure rake test is supposed to work on the test environment by default ?
EDIT 4
Please help!
EDIT 5 - SUMMARY
When running rake test in my computer or on our server in Rails 3.0.7 with different apps it does the following :
run CREATE TABLE and INSERT INTO migration against the dev. db.
do not empty the dev. db.
development.log gets written not the test.log
also an issue with the error unknowm comman 't' with one specific app.
EDIT 6 - db config
Nothing change from the default yet : https://gist.github.com/1006199
EDIT 7
rake db:test:prepare --trace -> nothing break (but keep printing (first_time)
https://gist.github.com/1007340
With RAILS_ENV="test" for rake, everything goes fine. It write on the test logs.
ruby -I test test/unit/category_test.rb same erros than with rake, but no write on the dev. or test logs.
a bunch of unorderd answers:
the "CREATE TABLE" statements usually means that your test_db is created from scratch (by default, before test task, a db:migrate is launched). are you sure they're called on dev_db?
also check your config/database.yml to see if there's some typo (eg: using same table for test and dev environments)
it looks like there's an error in some of your migration files (that 't' error remember blocks in migrations).
"rake test" is the default task, that's why it's run when you just launch "rake" without arguments.
EDIT:
according on what I see on edits, from 5 and above, it looks like you have some issue with environment files. so try to double-check:
* config/environments/test.rb
* config/application.rb
* config/environment.rb
if with RAILS_ENV="test", everything goes fine, then I'm almost sure you have changed some default behaviour in your app (configs, env variables, any particular gem?)
also, in your test/test_helper.rb, add RAILS_ENV='test' at the beginning of file, this should force test environment.
I had that same error message, except to me it said: in `test': unknown command 'i' (ArgumentError).
The 'fix' or 'workaround' was to simply use:
$> bundle exec rake test
instead of using 'rake test'

Why is RSpec so slow under Rails?

Whenever I run rspec tests for my Rails application it takes forever and a day of overhead before it actually starts running tests. Why is rspec so slow? Is there a way to speed up Rails' initial load or single out the part of my Rails app I need (e.g. ActiveRecord stuff only) so it doesn't load absolutely everything to run a few tests?
I definitely suggest checking out spork.
http://spork.rubyforge.org/
The railstutorial specifically addresses this, and gives a workaround to get spork running nicely in rails 3.0 (as of this moment, spork is not rails 3 ready out of the box). Of course, if you're not on rails 3.0, then you should be good to go.
The part of the tutorial showing how to get spork running in rails 3.0
http://railstutorial.org/chapters/static-pages#sec:spork
Checking when spork is rails 3.0 ready
http://www.railsplugins.org/plugins/440-spork
You should be able to to speed up your script/spec calls by running script/spec_server in a separate terminal window, then adding the additional -X parameter to your spec calls.
Why is rspec so slow? because it loads all the environement, loads fixtures and all that jazz.
Is there a way to speed up Rails' initial load you could try using mocks instead of relying on the database, this is actually correct for unit testing and will definitly speed up your unit tests. Additionnaly using the spec server as mentionned by #Scott Matthewman can help, same with the autotest from zentest mentionned by #Marc-Andre Lafortune
Is there a way to single out the part of my Rails app I need (e.g. ActiveRecord stuff only) so it doesn't load absolutely everything to run a few tests? what about this
rake test:recent
I am not sure how the rspec task integrate with this but you could definitely use the test:recent task as a template to do the same with rspec tests if the.
rake test:rspec:recent
doesn't exist yet
because it loads all the environement, loads fixtures and all that jazz.
The real culprit is if you run it using rake spec, it runs the db:test:prepare task.
This task drops your entire test database and re-creates it from scratch. This seems ridiculous to me, but that's what it does (the same thing happens when you run rake:test:units etc).
You can easily work around this using the spec application which rspec installs as part of the rspec gem.
Like this:
cd railsapp
spec spec # run all specs without rebuilding the whole damn database
spec spec/models # run model specs only
cd spec
spec controllers/user* # run specs for controllers that start with user
I think the "zen" experience you're looking for is to run spec_server and autospec in the background, with the result being near-instant tests when you save a file.
However, I'm having problems getting these two programs to communicate.
I found an explanation here:
I've noticed that autotest doesn't send commands to the spec_server.
Instead it reloads the entire Rails environment and your application's
plugins everytime it executes. This causes autotest to run
significantly slower than script server, because when you run the
script/spec command the specs are sent to the spec_server which
already has your Rails environment fired up and ready to go. If you
happen to install a new plugin or something like that, then you'll
have to restart the spec_server.
But, how do we fix this issue? I'm guessing it would involve downloading ZenTest and changing code for the autotest program, but don't have time to try it out right now.
Are you running this over Rails? If so, it's not RSpec's initialization that's slow, it's Rails'. Rails has to initialize the entire codebase and yours before running the specs. Well, it doesn't have to, but it does. RSpec runs pretty fast for me under my small non-rails projects.
Running tests can be really slow because the whole rails environment has to load (try script/console) and only then can all tests run. You should use autotest which keeps the environment loaded and will check which files you edit. When you edit and save a file, only the tests that depend on these will run automatically and quickly.
If you're using a Mac I recommend using Rspactor over autotest as it uses a lot fewer resources for polling changed files than autotest. There is both a full Cocoa version
RSpactor.app
or the gem version that I maintain at Github
sudo gem install pelle-rspactor
While these don't speed up individual rspec tests, they feel much faster as they auto run the affected spec's within a second of you hitting save.
As of rspec-rails-1.2.7, spec_server is deprecated in favor of the spork gem.
The main reason is that require takes forever on windows, for some reason.
Tips for speedup:
spork now works with windows, I believe.
You can try "faster_require" which caches locations:
http://github.com/rdp/faster_require
GL.
-rp
If you are on a Windows environment then there is probably little you can do as Rails seems to startup really slowly under Windows. I had the same experience on Windows and had to move my setup to a Linux VM to make it really zippy (I was also using autotest).

Resources