We are working right now with Ruby, Cucumber and Selenium to perform our integration tests.
Right now we want to improve the quality of our tests and therefore we want to use Capybara.
Now since all our methods need to be rewritten for that, we thought maybe someone has already done that and wrote a wrapper for the selenium webdriver, where Capybara does the job.
For example:
The wrapper should replace the following:
driver.navigate_to "/home"
to something like
visit "/home"
The point is, we don´t want to rewrite all our code, since the functionality out of my view is quite of the same and it should not be that difficult to write a wrapper for driver, which does this automatically. Means: the navigate_to method just calls a visit method, and I am happy.
Do I have to write this on my own, or was this already done?
Thanks alot!
No, there is no existing wrapper for that.
You seem to be missing the fact that Capybara is itself a wrapper around selenium-webdriver, so you are asking for a selenium compatible wrapper around a wrapper around selenium. This coupled with the fact that if all you do is emulate your existing selenium commands with Capybara commands you won't be gaining anything from Capybara, so it's pointless. It sounds like your team would be better off leaving the existing tests as they are, writing all new tests using Capybara, and as existing tests need change/maintenance rewriting them to use Capybara with it's built-in waiting/retrying and friendlier API.
Related
I would like to ask if anybody knows an easy way to test Telerik controls with Watin.
We are about to start using it but before we do I wanted to see if there is anything I would need to know.
The problem that I can see we will be having is that if even smallest thing changes then all our tests will also break.
Any suggestion is greatly appreciated.
The problem that I can see we will be having is that if even smallest thing changes then all our tests will also break.
This could/will be true of all portions of your pages, including Telerik controls, depending on your test structure. Ideally, your elements will have IDs assigned and you'll use Page classes and custom control objects to remove all HTML references from your actual test code. Then if something changes on the webpage (or in a control), you verify the change is expected, then you change the WatiN page code (or control code) and re-run your tests.
The WatiN page class primer is here: http://watinandmore.blogspot.com/2009/06/introducing-page-class.html
Basically, you want to have your test code look like myPage.PickDate("3/29/2012") and not like ie.Tables[3].TableRows[2].TableCells[4].Textbox(Find.ByClass("datePicker")).TypeText("3/29/2012")
Changes can, do and should result in failing tests, however, I can attest that with a good page (or control) class setup that abstract away the HTML DOM and other specifics leaving non-HTML-filled test code, means that when changes do happen they are most often easy to get working again.
Note: Selenium also has a Page class concept, but I have not used it very much as of right now. Bottom line: If you write a lot of tests that reference the HTML DOM directly in test code, you're setting yourself up for a maintenance headache regardless of if you go with WatiN or Selenium or whatever.
Added: As to your original question: Can you work with Telerik controls in WatiN? Yes you can most likely, but depending on the control you may need to get a bit creative, possibly even calling javascript methods from within your test (page object ;) ). I've been stumped by a couple controls (non-Telerik) but most I've eventually figured out.
I realize you asked about WatiN, and I know I'll probably get downvoted into oblivion, but I might recommend Selenium instead. It seems to be more widely used and when we were evaluating the two we found Selenium easier to work with because of the Firefox plugin to record/generate the tests. This meant that our non-technical folks could set up the tests.
Since then we've successfully used Selenium to test ASP.NET sites that utilize Telerik controls. I only ran into one issue, with the RadNumericTextBoxes, which I've documented a fix for here: http://www.msigman.com/2012/02/entering-radnumerictextbox-selenium-webdriver-1-6-0/.
I'm currently in the process of writing a how-to guide for doing it: http://www.msigman.com/2012/03/automated-testing-asp-net-web-application/ (shameless plug).
You should also consider evaluating Telerik's Test Studio, our functional automation test tool. (Disclosure: I'm their evangelist for Test Studio.)
Test Studio really shines when you're working with Telerik controls. You'll get some great additional functionality around being able to dive deeper in to verifications and actions around the controls.
Even more importantly, Test Studio handles centralizing locators and pages by default, so you don't need any additional effort to best manage your UI changes.
If possible does anyone have a template for setting up selenium tests using a pageObject design pattern.
What i would like to do is create a parent class which opens the browser. I can then pass that browser variable to another subclasses for pages such as LoginPage etc etc.
If anyone could be further information on this that would be great.
My main problem is getting the subclasses to inherit the browser variable.
I would really appreciate some help with this, any answer welcome to help point me in the right direction.
Cheers,
Jon
There is a page objects Gem. it works with both watir-webdriver and selenium-webdriver.
We had a 4 hour class on using that gem, watir-webdriver and cucumber at the recent test automation bazaar conference. you can find it here
Give it a shot, you can use it with either.. (and you may find you prefer the watir api to what selenium uses (I know I do) and if you like selenium, well that's an option too since the gem supports both
We are currently running rspec tests that check for specific libraries/models to be loaded. Specifically, we want to test that when creating an object, we get the correct Watir object back: Watir::Browser for FF and Chrome, and Watir::Safari for Safari.
We already tried doing this: Unload a ruby class but it just deletes the constant, which isn't what we want.
Normally, this wouldn't be a problem but due to compatibility problems with safariwatir and watir-webdriver, this is not the case. It errors out with:
superclass mismatch for class UnknownObjectException
And to 'fix' this, we basically have to choose which webdriver to load(hence the original logic - which we plan to test)
Is there a way to solve this? Our tests pass, not just when ran as a whole. So we basically have to skip a step just to circumvent the require problem.
New Anser: NEWS FLASH webdriver now supports Safari! ditch safariwatir and do it all with webdriver. I just found this out today at the Test Automation Bazaar, so don't have much in the way of details.. I'd expect to see some blog postings about this from the Watir community in the next week or so once people recover from the conference.
UPDATE: Details now up on the watir-webdriver blog regarding how to make things work with Safari
Classes in Ruby are objects, but the idea of classes as a 'one per execution/objectspace" only exists because Ruby class objects are assigned as constants.
Since your classes are namespaced with theater module, you can check the type of an object dynamically. If that isn't enough, you can duck-type. Since you mentioned compatibility issues, there are methods that exist for one that do not for another (which you can test for) or there are methods that return different values for each (which you can test for.)
I've handled something similar to this by using conditional logic when I require the 'watir' gem, so that only one version ends up being required based on what the environment is configured for. I can provide more details later, perhaps after the watir test automation bazaar is over and I have a little time to think and dig out some code samples for you.
I'm new in ruby and programming stuff in general. I have one, maybe silly question
is possible to use all the methods from rwebspec with watir-webdriver. And if it is possible, please show me.
Thanks
RWebSpec is a wrapper for all the Watir/Selenium-WebDriver methods. So by using it you are essentially using these underlying tools. There's no reason you need to explicitly need to use Watir-WebDriver.
I am learning Rails the age old way. By reading Agile Web Development with Rails (3rd Edition) as a starting point. I am currently in the chapter that teaches Testing. I am also aware of other BDD Testing framework such as RSPec. So I was wondering if frameworks such as RSpec, Cucumber, Shoulda replace the need for knowing/using Test::Unit? Are they both relevant in their own right and used for different purposes?
UPDATE: Since I am new to Testing, I would also love to get feedback on what resources are useful to get my feet wet with different frameworks.
Thanks!
The world has changed! Check down and upvote #prusswan
I think Test::Unit is still relevant even though there is a lot of hype surrounding BDD and other testing tools.
That being said, if you are up for it, you could bypass learning Test::Unit and start with something like RSpec and Shoulda right away, but there is something to be said about following through the examples in the Agile Web Development Book to see where the ideas from BDD came from.
I find myself still using Test::Unit for some projects since it comes with Rails and is still a very great testing framework.
So long story short, I don't think it's obsolete but it's not the cutting edge any more. BDD is a testing paradigm shift especially if you start using Cucumber and Webrat, but it's fantastic once you get into it. Shoulda is the easiest to make the transition to, so I would start with Test::Unit, then move to Shoulda, then Give RSpec and Cucumber a try.
You are testing or at least interested in testing! That's the best part. In the end it doesn't matter what you use as long as you are happy with it.
Good luck!
DHH himself is one of the avid users of Test::Unit and avoider of RSpec / Cucumber for their relative complexity.
I respect the guys behind it and I'm all for experimentation, but the proliferation of rSpec and Cucumber makes me sad.
RSpec offends me aesthetically with no discernible benefit for its added complexity over test/unit.
Cucumber makes no sense to me unless you have clients reading the tests. Why would you build a test-specific parser for English?
The important thing is of course that we get people testing, so tools shouldn't matter too much. But the added complexity still upsets me.
"something.should be_true" sums it up the aesthetic argument for me pretty well. That call hurts my eyes vs "assert something".
If you are interested, keep reading the twitter as of these twits.
Just thought I would post an update from 2012:
Out of the three main and current (usable with Rails 3.2 with no more than some minor modifications) introductory books on RoR, two of them are using Rspec (with at most a short mention for Test::Unit) and one of them is planning on even moar Rspec for the next edition, so it is clear who would be the winner of this "battle" for now
And allow me to selectively quote dhh:
The important thing is of course that we get people testing, so tools shouldn't matter too much.
Revisit in 2014:
Minitest has now superceded Test::Unit as a default in the current versions of Rails. Personally I feel it deserves a closer look compared to its predecessor for a number of reasons -
Its status as a default
Better support for capybara and selenium, a large part due to gems like this
Relatively lightweight
Mostly backward compatible with Test::Unit
Rspec is an entirely separate testing framework. Shoulda is an enhancement to Rails's built-in framework, Test::Unit. If you're using Shoulda, you're using Test::Unit but with more capabilities and simpler, more readable syntax.
I've tried Rspec and Shoulda and for me, Shoulda wins hands down. I like it way better. But that may be a matter of taste.
Note that you can use Cucumber with Shoulda.
Other resources? I recommend the ZenTest and RedGreen gems. ZenTest provides autotest, which lets you run your tests automatically every time you change a file. It's a big help.
Regarding fixtures vs. factories, if you need to set up a bunch of interrelated objects where you're testing both sides or a parent-child relationship and/or testing many-to-many relationships, fixtures work a lot better. Actually I'm not even sure you can do that with factories. So don't dismiss fixtures -- they have their uses.
There are a lot of people who still like Test::Unit, and to some extent, it's a personal preference. However, on balance, you will find far more activity on the RSpec front. The really cool stuff is all being done with RSpec and Cucumber, so if you don't have a personal preference yourself, I'd probably skip Test::Unit. You should, however, be familiar enough with it to read someone else's tests that are written with it, but I wouldn't foresee that ever being a problem.