this is my first stackoverflow question.
I am building an app that gets posted an email from SendGrid, which I then want to parse in a delayed job.
My concern is how do I QA this. I have been reading about Cucumber and that sounds like a good solution but I can't figure out the end to end test flow.
Here's where I am so far.
I want to have a large list of TXT files that include various types of email body's
I then iterate through each txt file, and make sure that when passed to a method in my lib directory /mailingjob.rb, that what is returned matches something defined in cucumber.
So what I have so far is something like:
expected = File.open('???/mail1.txt', 'r') do |f|
f.read
end
That's where I'm starting. So if you can, please help me understand the following:
Where should all these TXT files be located in the rails project directory?
One e2e example showing how to grab a local text file, pass it to a method in the /lib directory, and then make sure what is returned equals what is set for that file path.
Thank you thank you for any help you can provide
I would probably store these files somewhere in your test or spec directory (depending on what testing framework you use; you mentioned Cucumber, which I'm not super familiar with, but I think it uses a directory called features). Really, you could put them anywhere you want, but some subdirectory of your test directory makes sense.
If you're not familiar with testing with Cucumber, I recommend Railscast episode 155 and episode 159 to get you started. To answer your direct question, you would read the email from the text file as such
email_text = File.read("#{Rails.root}/test/path/to/email.txt")
Rails.root always refers to the root directory for your project, and makes it easy to build paths to other files or folders.
Related
I am currently coding an application in Ruby that does some simple external API calls to Soundcloud's API.
I have developed a bunch of code inside a single .rb file and want to put this into the rails architecture. This Ruby file has the following classes:
class SoundcloudUser
class SoundcloudQuery
class SoundcloudFollowers
Currently I understand that I can put these classes into seperate .rb files, and then just put them into the /models/ folder which then gives me the ability to call these classes from elsewhere in my rails application (using require/include).
My question is simply, is this the correct way to go about this? I am familiar with rails, but I am new to transferring a Ruby developed project into the rails format. I tried searching best practices for this in the Ruby style guide but I didn't really find anything.
On a side note - I wanted to also create another class that acts as a ?service? wherein in checks my local database if an entry already exists in the database, and if not, then it will query new data. My side-question here would be similar - where would this .rb file for this 'service' live?
I hope I explained my question clearly enough, if not, I am happy to add some clarifications. Thank you for your time!
If in Rails, you can put them in either lib/ or somewhere in the main app directory. For example, you can create app/services and put them inside there, and when you restart the Rails server you should be able to call SoundcloudUser (provided you name them app/services/soundcloud_user.rb.
I always look at the Gitlab source code for this. It's a gigantic Rails app but look at this file: https://github.com/gitlabhq/gitlabhq/blob/master/app/services/gravatar_service.rb. Because it's inside an app/services (any name actually), GravatarService can be called from anywhere in Rails. If you want to have some namespacing, you have to put it in app/services/soundcloud/user.rb or lib/soundcloud/user.rb and name the class Soundcloud::User.
For the class that acts as a service, it seems like it orchestrates the logic of "check if (song?) exists, else scrape. Some people put it in a model class, I'd probably put it in a service class a la the Gitlab source code. Hope I helped.
I am building XML files inside my application and I would like to validate the generated XML's format against an XSD file. I am not sure where shall I put this schema.xsd file so that it can be easily retrieved inside an RSpec example.
I was thinking about putting it inside spec/support, but I am not sure about it.
I would suggest spec/fixtures, since it is part of your test suite, it's somewhat static data and it can be accessed easily via fixture_path (you can set any other *_path helper in your spec_helper file if you wish to).
I've ended up putting my .xsd file in spec/support/schemas/; it felt more natural for me, since it is a support file.
I'm trying to create a rails app and have it on github, but I'm running into some trouble separating out personal settings from what I check in to git. Just like how you typically check in a database.yml.example and let people make their own database.yml, I wanted to do that with a bunch of other files (all rb files though), like secret_token and production.rb, but I didn't feel like making the setup process involve copying 15 sample files to files that actually get used.
What I ended up doing was creating a settings.yml.example file in my config dir, and putting all of those settings from the other files in there. then the setup process was just 2 copies (database.yml and settings.yml). Then I added this to the beginning of environment.rb
#allow files to read their private settings from settings.yml using SETTINGS
require 'yaml'
SETTINGS = YAML.load(IO.read(Rails.root.join("config", "settings.yml")))
and when I needed something from the file, I would just say something like
Foo::Application.config.secret_token = SETTINGS["secret_token"]
This worked fine until I tried to run rake test, when it gave me uninitialized constant Rails (NameError) from the Rails.root.join call
My question is is this a good way to accomplish what i'm trying to accomplish? And if so, is there a better place to put the code that loads the settings file? It seems like I can load it before each individual call and just add something like "unless settings is defined" after the load, but that would be annoying to have to do everywhere
Note: For anyone who's curious, the files I would have had to copy were
secret_token.rb
production.rb (for config.action_mailer.default_url_options)
devise.rb (for config.pepper)
I expect more in the future as i start using more libraries (still new to this)
this was answered in a comment, so I'll copy Thomas's answer here to make it more clear.
Both figaro and econfig (by the creator of carrierwave and capybara) are great gems for that purpose. I personally use figaro with it's config/application.yml file that is excluded from version control to great success since a few months on open-source projects.
Was digging around my Rails applications and noticed that there are rails.rb files all over the place. In my ruby gems directories like:
...gems\devise-2.0.4\lib\devise\rails.rb
...gems\cucumber-rails-1.3.0\lib\cucumber\rails.rb
...gems\railties-3.2.3\lib\rails.rb
I am assuming that there are executed whenever you issue some command like "rails xxx". So all these extra rails.rb files combine with the original rails.rb file to essentially make one big rails.rb file. Essentially, when we type in "rails xxx" it goes thru all them all?
Just looking for some confirmation PLUS a little more knowledge about this. Thanks.
The best way to understand what these rails.rb files are doing, is to read the source code.
ralties
devise
cucumber-rails
As you can see, in any library the file assumes a different scope. The common behaviour is that the file rails.rb normally contains the code required to initialize the library when loaded from a Rails project.
BTW, this has nothing to do with the script/rails command and there is no "big rails.rb" file.
The files are not generated but are simply source files of these libraries you are using.
In this case they are probably rails-related classes that either extend Rails in some way or modify it or make the library interact with Rails.
Rails is a very common framework in Ruby land so most if not all libraries will have some sort of integration with Rails.
By no means are all of those loaded when you run rails XXX but rather when your application loads these libraries their rails.rb files may be executed to provide some sort of integration with Rails.
For some reason, I find it really irksome that the files for each testing framework (rspec, test::unit, cucumber, etc.) live in a separate folder in the top level of my app. Is there a strong reason these directories should be scattered about instead of consolidated like gems/plugins in the vendor directory?
If there isn't an actual reason for the way it is, would it be kosher to consolidate these directories into a top-level "test" directory, containing subdirectories for each of the testing frameworks alongside fixture data, etc.? Has anyone else ever been driven bonkers this (and maybe already hacked together a quick'n'easy way of updating the necessary paths to get this to work)?
I for one would welcome this change.
Personally I use RSpec and Cucumber at the same time and I'm torn whether or not to put the fixtures in the features/support/fixtures directory (I create it myself) or spec/fixtures. What if I use this fixture in features and in spec tests too?! [overly emotional] Why won't somebody think of the fixtures!!
Definitely. A top-level test directory with the subdirectories of features, specs, fixtures and whatever else you need.
Great question!