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!
Related
I am working on a project where the current developers have put their "Plain Old Ruby Objects" in the models directory of our Rails app.
I have seen most examples online where the PORO files go inside lib instead, but some say models.
Is there even a logical / specific reason why people put them in the models directory over the lib directory?
"Idiomatically" the models directory intended for code used to hold state. Most of the time this would be ActiveRecord subclasses corresponding to database tables. However frequently people put other stuff in the models directory. One thing often seen are code dropped here in order to take advantage of auto-reloading. (the lib dir doesn't normally auto-reload)
Based on the Getting Started Rails guide, the app/models/ directory is pretty much anything, whereas lib/ is for modules that are used across the entire app (e.g. extensions).
As #seand said, yes, one advantage is that the app/models/ directory automatically reloads, but I tend to think of it as any class that "interacts with other classes" should live in app/models/, with the only exception being a service class (which I tend to think of as "a class which manipulates the state of another class"), which I tend to put into app/services/.
I know a lot of developers would disagree with me - many I've talked to even create a separate directory namespaced to their app (e.g. if your app is named "MyBlog", they would create an app/myblog directory for any object not explicitly backed by the database, but not a module or a service class either.
That said, I think ultimately it boils down to a) personal preference and b) where you feel is best to place the PORO with respect to your app.
There is no hard and fast rule on where to put POROs. The rails community has been hashing this out for a while now. At one point the convention was to put stuff in the concerns directory but that seems to have fallen out of favor with some folks.
One rule of thumb for the difference between /lib and app/{blah} is that code in the /lib folder is code that you presumably can reuse across several projects e.g. general purpose class or utilities. for example if you have some custom monkey patches to core ruby or rails classes that you will use in multiple projects, a good place to but them would be in the lib folder. Anything in app/{blah} should pertain specifically to current project.
One way to think of lib folder is as the poor cousin of plugins and gems.
Just my 2 cents on the subject
I feel like I understand the difference between require and require_dependency (from How are require, require_dependency and constants reloading related in Rails?).
However, I'm wondering what should happen if I use some of the various methods out there (see http://hemju.com/2010/09/22/rails-3-quicktip-autoload-lib-directory-including-all-subdirectories/ and Best way to load module/class from lib folder in Rails 3?) to get all files loading so we:
don't need to use require_dependency all over the place in the application and
don't have to restart development servers when files in the lib directory change.
It seems like development performance would be slightly impacted, which is not that big of a deal to me. How would performance be impacted in a production environment? Do all of the files generally get loaded only once if you are in production anyway? Is there a better way that I'm not seeing?
If you could include some resources where I could read more about this, they would be greatly appreciated. Some blog posts said that this behavior changed recently with Rails 3 for autoreloading lib/* files and that it was contentious, but I didn't see any links to these discussions. It would be helpful for considering the pros/cons. Thanks!
The code reloader is disabled by default in production. So if you are calling require_dependency at the top of a file it is going to be executed only once.
The Rails 3 change you mentioned is really small. You can usually call Foo and it will be loaded from app/models/foo.rb automatically. Before it could also be loaded from lib/foo.rb. (These directories app/models and lib are called autoload paths.) Rails team decided to remove lib from autoload paths in the 3rd version. You can still put it back. But it is encouraged to leave in lib less frequenttly-changed and project-specific files. If you have something that does not belong to any of the default app subdirectories like app/models or app/controllers you don't have to put it in lib. You can add your own subdirectory. I have app/presenters, for example. There is a discussion on the old issue tracker if you want more info on that.
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.
I'm attempting to reopen the String class in rails and add a bunch more methods for my app to use. Writing the code isn't a problem - my question is rather about where this code should go.
It doesn't make sense to me to reopen a class inside a different model file, because it really has nothing to do with any of the models specifically. I thought perhaps somewhere in config or lib would make sense, but I'm not particularly well versed with RoR yet.
To summarize, where would be the most logical place to define class-modifying code, and are there any implications depending on where/when the code is loaded?
The most logical place is probably in a file in the config/initializers directory. Any *.rb file you put in here will be automatically executed when rails boots. If you want, you could put them in a sub folder, so you could do something like config/initializers/extensions/*.rb.
I try keep these monkey-patches to a minimum, only when they are very clearly in the best interest of my code.
Lately I have preferred to keep the files organized in folders such as lib/monkey/string.rb, lib/monkey/hash.rb, etc. I then require all files in the lib/monkey folder in my environment.rb file.
# Load all monkey-patches.
Dir["lib/monkey/*.rb"].each {|monkeyfile| require monkeyfile}
This keeps all of my class modifying code isolated to one location, should a problem arise. I also enjoy the somewhat goofy naming, because it makes it stand out as something to be mindful of. Someone may have a better system, if so ... I'd love to hear about it!
I have some integration points where I want to test various responses - where do you think should I store these artifacts in my spec/ directory of my rails application?
In the past I've created a test/resources or spec/resources directory for other test/spec related files. That seems to keep it clear that it's some sort of other file used only for testing.
you could just create a spec/fixtures dir and stick em in there.