When developing a project, I turned to shoulda for testing just because it's what I was familiar with. However, the project hasn't had a release in over a year. I'm wondering if anyone has recommendations on alternatives, or if I should just stick with shoulda?
The remarkable gem is the closest I've found to Shoulda. Unfortunately it looks like it hasn't been updated in even longer. It also relies on RSpec and it not compatible with Test::Unit.
It isn't clear to me how well it supports Rails 3 - although there are some instructions for getting it up and running.
After looking into both Shoulda and Remarkable I decided to go with Shoulda as it still seemed the more likely set of helpers to be updated.
One of the issues you will have with shoulda is that Thoughtbot uses RSpec rather than Test::Unit, which is part of the reason that the Shoulda gem (which exists for the benefit of Test::Unit users) has seen little activity - the RSpec component of the gem, shoulda-matchers, has been updated much more recently. Thoughtbot also found a new maintainer for shoulda-contextin Jan 2012 (this is the gem required alongside shoulda-matchers to get everything working in Test::Unit - the shoulda gem really only pulls in shoulda-matchers and shoulda-context) so there should be more focus on the Test::Unit side moving forward I expect.
Hopefully these moves give at least a little confidence that Shoulda for Test::Unit will be updated more frequently moving forward. In the absence of any other suggestions I would stick with Shoulda for the time being.
Rspec is the most common BDD framework used for testing in ruby and is quite popular. It works well with shoulda assertions in case u like some of the assertions in shoulda. Ruby also ships by default with test/unit for testing.
Between, what are the issues you have with shoulda at the moment?
Related
I have read Rspec from RubyonRails Tutorial 3 book. But i am actually not getting the language what it is trying to explain.Please can anyone explain me in simple way for easy understanding of it.
At its core, RSpec is just a ruby library for automated testing, just like Test::Unit or Minitest. The thing with RSpec is that it uses very special syntax and method names to make the test code read like english prose. This is done to give the reader a better understanding of the test code and make it easier to read, although whether RSpec achieves this is controversial and highly subjective.
If you're still having trouble understanding RSpec, I recommend this tutorial. It teaches RSpec as part of regular Ruby on Rails development.
What I understand so far is that RSpec (and test-driven development in general) is a method of developing programs while ensuring that the program does what you want it to do. The process is three-part:
Write a test to test for a new feature. The test will fail because you haven't written the code yet.
Write the code for the new feature.
Run the test and modify the code until the test passes.
I've been meaning to get into testing. After reading about a few testing frameworks (test::unit, Rspec, etc). I've decided give Rspec and Capybara a try.
I'd like to understand how experienced developers utilize these libraries properly. Which in-turn will help me write better application code and find bugs or little errors in the smallest cracks in the application.
Approaching this as a total TDD nooby. What online sources have you come across to help you learn about Rspec + Capybara. I found this Railscast, which is a good starting point. Are there any other sources / articles I should be reading?
I came across The Rspec Book, which is great for Rspec, but touches more on Cucumber examples.
In addition, how can I find out all the functions available for Capybara. i.e. fill_in, click_link, etc. The Github page mentions a few, but not all.
I also use Rspec with Capybara, and i get along very well with this references:
Action methods: http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Node/Actions
Find methods: http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Node/Finders
Match methods: http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Node/Matchers
Hope it helps!
If you were just starting out in rails which path would you encourage new users to go down with regards to Testing.
Anything I read about regarding Rails 3, tells me I should be using Rspec 2. But Rspec comes with a whole whack of other things I need to learn like
gem 'capybara'
gem 'database_cleaner'
gem 'cucumber-rails'
gem 'cucumber'
gem 'spork'
gem 'launchy'
And then one of my friends just told me that I should just stick to the testing framework that comes with rails, and maybe just integrate 'shoulda' into the test process because it has a nice syntax.
When it comes to testing it seems like we have way too many options and too many ways of doing something. Maybe this is a good thing, but I always thought rails was about creating common conventions and avoiding doing the same thing in different ways.
I'm fairly new to rails.
I'm unsure where to start.
I feel overwhelmed.
Is this normal?
Since you're beginning with rails, I'd recommend using something that "just works" to get in the habit of testing your code and understanding how to work with your framework. Don't waste your time comparing solutions, choose one and stick with it for this project.
That being said, I really think it depends on your experience developing software:
if you've never used unit tests for your code, learn Test::Unit and consider adopting TDD. Notice that TDD will need you to dedicate a large amount of time to it at first, but that is paid off when you get used to it.
if you have significant experience with code tests and are just confused on how to start with rails, I recommend following through http://railstutorial.org/book. This is a (free) Ruby on Rails book that uses RSpec, Spork and serves as a great introduction
After developing one project from start to end using the testing platform you choose now, you'll have a much better task of choosing the testing framework you wish to use.
I'd also recommend you learn RSpec well before diving into Cucumber.
Sounds like you have option overload. Which is common to most people in a lot of different situations even outside of programming. The absolute easiest thing for you to do, would be to go with what Rails sets up by default, which is called Test::Unit
Their official guide introduces it here: http://guides.rubyonrails.org/testing.html
Once you are comfortable with testing using plain Test::Unit style then I would suggest you explore some of the addons your friend mentioned such as shoulda (https://github.com/thoughtbot/shoulda), and factory_girl (https://github.com/thoughtbot/factory_girl)
Good luck!
But Rspec comes with a whole whack of
other things I need to learn like ...
Actually, you don't need to learn any of those other gems to get started with RSpec. Just go with gem 'rspec-rails, and run rails generate rspec:install to set up your project.
A good way to learn RSpec is to look at the code generated by rails generate scaffold. This creates spec files for controllers, views and routes that deal with the standard RESTful actions.
While learning RSpec you can add in other gems as you discover the need for them. Autotest is essential IMHO. Webrat adds useful matchers for view specs. Factory_girl adds support for factories.
Spork is great, but not really necessary until you have enough specs that performance is an issue.
I feel overwhelmed. Is this normal?
Less of this, more of this :)
We are using Qtp as a testing tool, and currently planning to move to an open source testing tool. We have zeroed in on Watir and Selenium as two potential tools for this purpose. We have done some study of these two products and have liked Watir for its neat and powerful API and ease of use. We are only looking at testing on IE; hence cross-browser support provided by Selenium is probably not so important.
But, as my research on Watir progressed, there is one thing about Watir that is disturbing me a little. That is the losing momentum that I see about the product. Most of the articles, success stories and quotes are pretty old - say earlier to 2009. Hardly anything exciting being written about Watir in 2010. To add to this, I hear this story about Webdriver going to replace Watir. Though i couldn't find many articles on Watir-Webdriver, i saw this article on watir that is somewhat of a concern to me as it says watir is DEAD.
http://www.natontesting.com/2010/04/14/explaining-watir-selenium-and-webdriver/
We do not want to start with a product that is probably already dead, or dying.
Can any one please tell me what exactly is happening in Watir and what is the roadmap ahead?
Thanks,
Babitha
You can also check out the source code and it's history directly from GitHub https://github.com/bret/watir/commits/master/ to see if there's any activity.
But it's true that Watir had some longer period of inactivity in terms of releasing new versions http://rubygems.org/gems/watir/versions
As you can see then the time between 1.6.5 and 1.6.6 was almost a year. But nevertheless Watir is not dead nor planning to die. Also, you have got that right about Watir-Webdriver being Watir 2.0 in the future, but i'd not recommend it just yet for IE due to it's early alpha state and some pretty critical bugs. It's repo is here https://github.com/jarib/watir-webdriver
If you have any questions or problems related with Watir, don't be afraid to ask them in here or in Google groups at http://groups.google.com/group/watir-general
Watir is alive. Take a look at watir.com, you will find all information there. If you have further questions, ask.
In the same blog (that the page on natontesting.com mentions), Alister has discussed the impact of web driver on the future of WATIR.
He says:
If you’re a Watir user, it doesn’t really make that much difference. If you think of automated web testing as a car, Watir is the steering wheel and dashboard, which interact with the engine. Allowing Watir users to use WebDriver is like providing an additional engine choice, but keeping the steering wheel and dash the same.
Ultimately, I think that Watir will remain a very popular automated web testing tool, one that has been designed by testers for testers. I can see the usage of WatiN and Watij reducing as more developers move to Selenium 2.0/WebDriver which will offer the same functionality as Watir using a different API and multiple programming languages. If WebDriver can focus on the detail of controlling browsers, ultimately Watir will be a better tool as more effort can be spent on improving the Watir API, upgrading the steering wheel and dash, so to speak.
The point of that article is that both Selenium 2.0 and Watir 2.0 are incorporating Webdriver technology. Watir just put out a new release last month, Watir users are sharing tips everyday on the Watir General mailing list.
If I started a new framework today, I would be most likely to use Watir. I always keep an open mind, so I cannot guarantee what I would use. Maybe the project involves flex so I would try FunFX, or java developers want to be involved so I would consider webdriver with junit. But I would have no concern about using Watir into the future. I have used it for the past three years. I have known people who used it even before that. The community is too strong to die.
We used Watir for a while but ran into problems maintaining our Ruby environment. We're not a Ruby shop, so when we updated our version of Ruby and Watir stopped working we weren't fit to really understand why the breaks were occurring.
The lack of a good recorder was also a problem for us.
So we switched to Selenium, which has great recording capability and runs right in an NUnit test (we're onthe .Net platform), but Selenium doesn't execute successfully every single time. We had to write retry wrappers around the calls since they would work sometimes and not others.
Our quest to find something easily recordable that runs reliably continues. I've seen a lot on the forum about WebDriver and Sahi so I'll look into those. As long as we can spit out XML so we can integrate with CC, we're good.
As you already read, the WATIR community is alive and kicking! I just started the Automated Regression initiative at my company and one of the requirements was to utilize an open source tool (or a group of them). I came across WATIR and since its FOSS, Easy to use, and uses Ruby, I couldn't help but suggest the tool to Management.
Here's a tip (if you want it or not!):
WATIR is great stand-alone, but when bundled with CruiseControl (another FOSS tool that is a CI [Continuous Integration] Server), you can run your regression scripts all day long and get the xUnit reports from it (remember to utilize Ruby's built in Test Unit framework). Makes it real useful for the higher ups and your devs.
WATIR is alive and kicking and just recently came out with an update (1.67). The wiki is killer (http://wiki.openqa.org/display/WTR/) so go there first for your Q&As.
Have Fun with WATIR. Beats the pants outta silly old QTP any day of the week!
Hit me up if you have questions since this is still fresh in my head :)
The spec library in Minitest is great. I've been able to use it within Rails unit tests no problem. However, Rails functional test inherit from ActionController::TestCase which provides instance variables like #controller in it's setup.
Has anyone been using the Minitest::Spec lib for their Rails functional tests?
If not, I'm considering creating a small library to do just that. I'm not too keen on rspec, and shoulda is starting to shift it's focus to rspec. It would be nice to have something lightweight and built on tools already provided.
Thoughtbot have now split shoulda into shoulda_contexts and shoulda_matchers so the worry about a shift to rspec for thoughtbot doesn't mean shoulda contexts are going away. Just being maintained in the community.
Here's a simple test_helper rig to run functional & integration tests in Rails using spec syntax. Based on a gist by tenderlove, this excellent article about MiniTest with Capybara, & a lot of tinkering & source-poring.
https://gist.github.com/1607879
Maybe try http://metaskills.net/2011/03/26/using-minitest-spec-with-rails/.