I have a project with several features in cucumber both plain and selenium are failing indicating problems when trying to create a user because of the email uniqness validation (so the records are not being deleted and every background on the feature is failing)
I get a warning like this "WARNING: You have set Rails' config.cache_classes to false (most likely in config/environments/cucumber.rb). This setting is known to break Cucumber's use_transactional_fixtures method. Set config.cache_classes to true if you want to use transactional fixtures. For more information see https://rspec.lighthouseapp.com/projects/16211/tickets/165."
Weird enough all my enviroments have the session_cache set to true (just development hast it on false but I also tried setting it to true and run it)
Also the same project is working on other computers I tried uninstaling ruby and all the gems from rvm and reinstall but I still get the same error
Any ideas what else i could try to solve this on my mac? also database cleaning strategy is set to fixtures
I appreciate your time
I would try using a hook to clear out the data.
https://github.com/cucumber/cucumber/wiki/Hooks
A before hook that will do a .destroy on all records to ensure a clean start may be a good bet. It feels hacky to me, but may help you further diagnose the failure.
Related
I've been trying to run a rails db migrate command, and its worked on many apps with the same setup as this one, but for whatever reason I am getting the following error:
config.eager_load is set to nil. Please update your config/environments/*.rb files accordingly:
* development - set it to false
* test - set it to false (unless you use a tool that preloads your test environment)
* production - set it to true
But here's the thing. All of those are set correctly. I've even tried setting them incorrectly running it, and setting them correct again. I've restarted my computer, my app. Everything. I can't find a good explanation of what config.eagar_load even really is either. What is this thing? Why is it messing up my app? How do I even troubleshoot it?
Answer in part: I was using rails db migrate and should have been using rails db:migrate so that fixed the problem, but I would still like to know what config.eager_load is, and what it does.
I recommend you this great post.
I used to have 3 fixtures in my RSpec tests. I have removed them and went with the FactoryGirl approach. The problem is that, when I run my tests, even though I have no trace of fixtures left, they still appear when running the tests.
If I debug the tests, I can see that the fixtures' creation date is old, older than the objects created when running the current test.
I believe fixtures are somewhere cached, how can I clear this cache? Or, if this is not the case, why are the old fixtures there when running the tests?
rake db:setup will reload your test database from your schema.rb, erasing your fixture data.
After some deep digging, I found out that some sourced files were setting an env var with the development db, not the test db. Pretty trivial mistake, but so hard to find.
As a conclusion, if others stumble upon weird problems like this one, be sure to check whether you are using the right environment variables/configuration options in your app.
I am using rspec to test and I notice that after running the tests, it sometimes leaves some records in the test database. I'm not sure why. I have use_transactional_fixtures set to true in my config file. But they don't go away until I manually delete the records. Does anyone have a way to stop this?
EDIT; before i said it was only when tests fail. that's no longer true.
I found the problem. Before(:all) blocks are not transactional
Try database_cleaner gem.
Truncation or Transaction strategy will work for you.
Caution: It can make your test suite run terribly slow.
Normally, proper use before, after in RSpec(if you are using it) works usually fine.
I'm kinda new to RSpec.
I wanted to run some example Rspec spec ( using rake spec command), having
config.use_transactional_fixtures = false
in configuration file, as it was recommended in some manual.
But, it still wipes the database and it just frustrates me, cause I had sensitive data in it and now it's all gone. Who the hell actually came up with an idea of clearing the database during the testing ?
How to avoid this behaviour ?
Thanks in advance!
Transactions are there to ensure your test database stays clean so that your tests stay clean and predictable. You should be using them. To turn them off for singular example groups, use self.use_transactional_fixtures = false after the describe line. You will however if you do this need a after(:each) block that cleans up afterwards.
I don't understand why you have sensitive data in your test database, sounds like you're doing something wrong there.
I have some iPhone client tests that run against my development rails server. The whole suite runs an order of magnitude faster if I turn on class caching in the Rails config. On the other hand, that slows down development when I'm not actually running the tests.
I want the test suite to hit an action at the beginning to turn on class caching and another action at the end to turn class caching off again.
Is this even possible? If so, how?
Not without some serious hacking. Rails goes to quite a lot of trouble to make sure your files are reloaded on every request (when cache_classes=false). The value of the cache_classes configuration variable is used by initializers in several places not the least of which being:
using require to load ruby files when cache_classes is true (meaning they are no longer reloadable)
setting up dispatcher callbacks to reaload the application on every request when cache_classes is false
You do have access to the value of the cache_classes variable, and you can even change it if you like:
Rails.configuration.cache_classes = true
But, this will have no effect on the running rails instance as the initializers where that value is used only run once when the rails app starts up.
What this means is this, unless you're prepared to invest some serious time and hacking effort you can't really avoid a restart of your server. So, what you need to look at is controlling this restart process via your test suite.
For example you can try to restart rails from within rails. This would allow you to define an action that your test suite can hit right before it begins executing (to restart the server in the right mode), and another action which the server can hit after all tests have finished, to restart everything with cache_classes set to what it used to be. You would control the value of cache classes via an environment variable like this post suggests.
It would still require a bit of work to set all of this up and get it to hang together, but this is probably your best bet if you want an 'auto-magical' solution.
I don't think doing what you suggest will work.
But I suggest you may be looking for the wrong solution.
If what you want is to access your development database from your iphone testing,
then why not add a new environment.
Add a new file config/environments/iphone_dev.rb
require File.dirname(__FILE__)+"/development.rb"
config.cache_classes = true
And in your database.yml (or mongoid.yml or whatever)
iphone_dev:
host: localhost
database: my_app_development
There is no reason the database cant be the same
Now just run rails server -eiphone_dev -p3001
You should have a server, almost the same as your dev server,
but running on a different port, with caching enabled.