I have a Sinatra app with the following structure:
controllers
helpers
models
views
public
I will be using RSpec for testing it. For me, there are two variants of tests - to test with Rack::Test::Methods - to check responses, the content of body and so on, and the second - to test the "core" logic - for example if the method "find_most_expensive" really returns the item with maximum price, to check if a new product is really created and that kind of things.
What I'm wondering is how to organise this tests in the spec folder? Should I have only name_of_controller_spec.rb files and both kind of tests go there? Or should they be separate? And how? To sum up, I have never written tests and I don'y know how exactly and where to put them :( Any kind of advise would be appreciated! :)
You could make just three folders: controllers (with, for example, posts_spec.rb), models (that contains post_spec.rb where testing the methods you have implemented in your model) and helpers (let's say utils_spec.rb).
Take a look at Testing Sinatra with Rack::Test and some repositories on GitHub to have a better idea on how you should organize your code.
https://pragprog.com/book/7web/seven-web-frameworks-in-seven-weeks
The source code is free and it has a chapter on Sinatra tests.
I know, I just ran them as I updated the expect instead of should deprecation warnings.
Only they use shell scripts to test with but you may already be familiar with what you want to use. The point is notice just different names for the folders and not the tests? Maybe could work for you. I like the answer first posted. These can both relate perhaps.
Something I had noticed with Rubocop is to keep your test methods in as little as 25 lines or they fail there. So I would say keep them broken down into small groups.
Ruby koans has tests that you could look at too.
Related
Recently I made a simple ruby application and have been using minitest to test it.
Following the advice of the Head First Ruby book, I automated this testing using Rake(I'll write what it told me to put in the Rakefile at the end of this post, in case that helps). The test seems to run fine (everything passes in a way I would expect it to), but I always get this notification at the end of it all:
rvm/gems/ruby-2.3.0/gems/guard-2.14.0/lib/guard/notifier.rb:28: warning: instance variable #notifier not initialized
Testing things manually by telling ruby to include which files I want, does not have this issue, only when I use "rake test" to test things.
As far as I can tell, this is related to when I set up Guard when I was following Michael Hartl's Rails Tutorial, at the end of chapter 3. I followed the directions for setting that up (correctly, as far as I can tell), and this was all in a completely different folder(ultimately my ruby and rails projects do have the same parent folder that they sit in, but are themselves in completely separate ruby_projects and rails_projects folders). If possible, I would like to stop this notification on my ruby application that I am testing. Is there a good way to do this?
Contents of the Rakefile I am using, if that helps:
require "rake/testtask"
Rake::TestTask.new(:test) do |t|
t.libs << "lib"
t.test_files=FileList['test/**/test_*.rb']
end
My test file requires minitest/autorun, and the file for the application that I am testing, then has the normal tests
Seems like there's some weird conflict...
The reason is that Guard::Notifier.connect isn't connected. Normally, when you run guard, Guard.setup is called which does this.
If you're not using guard (e.g. interactively), then calling the following from your Rakefile should work around the problem:
Guard::Notifier.connect(notify: false, silent: true)
Guard::Notifier.disconnect
This will initialize the variable.
For a faster response, always report such issues on the project page on Github. If you can share the project where this occurs, maybe a better fix is possible. (It's best to provide a repository, since it really speeds up fixing things and often errors like this are very hard to simulate without the exact code).
i'm using Protractor and Jasmine and would like to organize my E2E test in the best way.
Example:
There is a set of the tests for check registration function (registration with right credentials, register as existed user, etc.).
I need to run those tests in three different projects. Tests are same, but credentials are different. For one project it could be 3 fields in the registration form, in another one - 6.
Now everything is organized in a very complicated way:
each single test is made not as "it" but as a function
there is a function which contains all tests (functions which test)
there is a file with Describe function in each
in that file there is one "it" which call the function which contains all tests
there is test suite for each project
I believe that there is a practice how to organize everything in a right way, that each test was in own "it". So will be happy to see some links or advice.
Thank you in advance!
Since it's a broad question, i will redirect you to few links. You should probably be looking at page-object model of Protractor. It will help you simplify and set a standard to organise your tests in a way that is readable and easy to use. Here's the link to it as described by Protractor team.
page-object model
However if you want to know why do we need to use such a framework, there are many shortcomings to it, which can be solved by using such framework. A detailed explanation is here
shortcomings of protractor and how to overcome them
EDIT: Based on your comments i feel that you are trying make a unified file/function that can cater to all the suites that will be using it. In order to handle such things try adding a generalised function (to fill form fields in your case), export that function and then require it into your test suites. Here's a sample link to it -
Exports and require
Hope this helps.
I just completed writing a detailed rspec capybara integration and unit tests for Rails app, which includes mocking Omniauth (twitter) login, filling in forms, data validations, etc. However, I am wondering whether there is a need to write a separate controller or functional test.
Would appreciate your input and any links to further readings etc.
I'll play devil's advocate here, since I know I'm probably in the minority with this opinion: I actually prefer to do exceedingly thorough controller testing. A few reasons:
1) I find it easier to systematically test every path and outcome at the controller level than at the integration test level. My integration tests are primarily just happy-paths, and some of the more common error paths.
2) A lot of potential security issues occur at the controller level. Thorough testing helps me ensure that nothing malicious can get through to my model logic.
3) This is subjective, but it really forces me to think about some of the long-tail paths that my application might go through. What if someone tries to for an invalid password reset token into the URL? Controller testing ensures that I consider all options.
4) Unlike integration tests, they're fairly straight-forward to test. Each action is just a ruby method!
Personally, I think if your request (integration) spec is exercising all code paths you're covered. Ryan Bates has a great Railscast about how he tests here: http://railscasts.com/episodes/275-how-i-test?autoplay=true and about 5:05 in he says a similar thing. Like you I like to write integration tests rather than controller specs. Most of the time controllers simply front CRUD type operations anyway (especially if you're careful about keeping domain logic out of the controller), so all you're testing is the scaffolding.
We have a isolated test automation team responsible for automating only watir+cucumber functional test cases. Their code base is not attached with the rails app that other developers are working on, but kept separate. We have automated several test cases so far, and now what problem we have is, some (watir/cucumber specs)test cases require some data to be preexist into db, so it(testcase) should focus only on the problem stmt, and not creating any data-require itself.
Example, say if it has to check whether rating is working for a post, it requires a post object should preexist and it just checks rating. And not creating 1st post object and then checking its rating.
What are the best approaches here? Like we have fixtures and factory-girl for rails unit testing, what is there for cucumber specs? Or Shall we make use of features only here? These testers may not have idea of all models that exist, do they be aware of them so to make use of fixtures by calling Rails-Model interface.
My idea was, when we write feature file, it should not point or talk about any Model which looks meta stuff. Watir/specs test cases should only be aware of "Web-application"/browser only as the interface to talk/deal with the application. They should not know any other interface(fixture/Models). Hence they should create their own data on their own, by making use of the single interface they know.
Again, what I want to know that, is there any ruby lib/code, given table names, column names, and values(all most like fixtures yml), along with db parameters. It will simply insert them into db, without context of rails environment. And so testers those are having their environment isolated from rails web developers would able to work on their own. Rails fixtures, or factory girls seem to be well coupled with rails. Or am I incorrect?
Like Chirantan said you could use Factory girl with cucumber.
As require your factories in test unit or RSpec, you can do the same in the cucumber's env.rb file or any custom config file.
http://robots.thoughtbot.com/post/284805810/gimme-three-steps
http://www.claytonlz.com/2010/03/zero-to-tested-with-cucumber-and-factory-girl/
http://www.andhapp.com/blog/2009/11/07/using-factory_girl-with-cucumber/
When using cucumber, the Given statement sets the test situation up:
Given I have a basic user with a password
and the When statement triggers the test:
When the user logs in
and the Then statement checks the test results
Then they see the basic menu
The data gets loaded in the Given statement.
I'm sick of writing out the same controller specs each time I make a new controller. I know I can use the scaffold generator, but there are enough little things I have to change that it usually doesn't save me much time.
Are there any projects/tools out there that provide some sort of base set of specs and/or a DSL to make this easier?
I've never found that any two REST controllers I wanted to write had similar enough interfaces that the tests were at all similar (and generally, I recommend Cucumber, not controller specs).
Something like inherited_resources or Rails 3's respond_with is very useful for writing the controllers, but I'm not sure about the tests.
I use the decent_exposure gem.