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.
Related
I have one rails spec file.
When I run: rspec my_spec.rb
There were 3 failures. These failures are in the same context.
But when I run them seperately (Example: rspec my_spec.rb:231),
they passed.
Rarely individually test also failed, if that, I restarted docker then it passed again.
I am not sure what was wrong?
I tried adding DatabaseCleaner.clean and redis.flushdb in spec_helper but no lucky.
Any idea can help?
Is very difficult to help you without the specs.But based on my own experience, usually this is a problem with hardcoded expects. Like:
expect(response.id).to eq(1)
rather then:
expect(response.id).to eq(object.id)
When you run your test only it works because of there one entity only. Check this and if it don't help, please provide us more information. Glad to help.
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'm having trouble with PaperTrail (auto-versioning of objects for Rails) being used with RSpec tests. Normally I want my tests to run without PaperTrail versioning, but there are a handful of tests for which I want PaperTrail turned on. I typically run my tests with Guard and Spork, and I can use things like PaperTrail.enabled = true and PaperTrail.enabled = false around a given test and everything works fine.
However, when I run the tests with RSpec, the tests requiring PaperTrail fail. To be more specific, it appears that while code in before filters can produce versions objects, code in the tests cannot. After a considerable amount of digging and tinkering and trying code snippets (I've tried this and this), it looks like the best solution is to use the require "paper_trail/frameworks/rspec" line mentioned in the PaperTrail README.
Unfortunately, each of these keeps me right where I started—tests pass with Guard/Spork but not vanilla RSpec. This is in particular an issue because while I use Spork locally, our continous integration server runs RSpec directly.
Does anyone have any insight?
PaperTrail now has documentation on tests with vanilla rspec
https://github.com/paper-trail-gem/paper_trail#7b-rspec
After including require 'paper_trail/frameworks/rspec' in your spec/rails_helpers.rb
... PaperTrail will be turned off for all tests by default. To enable PaperTrail for a test you can either wrap the test in a with_versioning block, or pass in versioning: true option to a spec block.
Somehow my issue was fixed by changing before(:all) and after(:all) behavior to before(:each) and after(:each).
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 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.