I'm absolutely new to CasperJS and I'm wondering what's the difference between those 'two modes'.
Both access the DOM, it seems that test mode has a limited access and functionality.
I looked for this question around and didn't find the answer.
In test mode you have access to the tester module and with it access to asserts, test suites and (xml) reports. This is not accessible in plain mode anymore (earlier versions than 1.1-beta4 had access to some of the test mode stuff in plain mode).
The only drawback to test mode is that you can only have one casper instance which is injected. This leads to:
When you try to create it, you will get an error.
(Nearly) all options have to be assigned directly and cannot be passed to create as an object.
Some things cannot be done like this one: A: How to open a new tab in CasperJS
Related
Can anyone briefly explain what are the common asserts to consider in any automation project please. Whether it might be an in-house or public web application. For example presently i am using selenium (java) to automate an eCommerce web application. As this is my first website to automate, i am running out of ideas where i can verify things expect few which i know mentioned below:
1.Verify each page Title
2.Verify a button, text, link, image, custom text etc
Apart from these is there any thing else i can verify? please feel free to correct my question and if you have worked on various automation projects which areas did you add asserts to verify or validate something on a webpage.
basically, you do automation to decrease the execution time of regression cycles by automating the Test Cases relate to the functionality of the application. so, first develop test cases, using test design techniques like ECP, BVA etc.
Each test case must have an Assertion called expected result or functionality (otherwise it won't be called a Test case).
This assertion can be anything like,
Whether login successful after giving valid credentials
Showing an error message after entering wrong credentials etc.
Selenium helps us to automate web interactions (navigations, clicks, enter texts etc.) and don't perform any assertions for you.
Assertions are available by frameworks like JUnit, TestNG (in Java) with Assertions class. There is built-in support from programming languages like assert keyword in python & Java (http://docs.oracle.com/javase/7/docs/technotes/guides/language/assert.html)
So, whatever you mentioned in your question like common assertions (Verify each page Title etc.), those are just web interactions. they don't decide whether a Test is PASS or FAIL. It is you who define the criteria whether a Test is PASS/FAIL.
For example, there is a test case related to successful login.
here, you automate web interactions like navigate to login page, enter credentials, click Submit button.
Then to validate whether you successfully logged in or not, you look for a web element in the Home Page of the user logged in (like, welcome user) in normal scenario. In Automation, you try to find the text welcome user using webelement. Then you use Assertions provided by frameworks, to assert whether the expected message is present in the webpage like
Assertions.assertEqual(expected_message, actual_message); // just an example.
If expected_message and actual_message is same, then the method don't throw any exception, which results in marking the testcase as PASS by the framework
If expected_message and actual_message is NOT same, then AssertionError is raised by the method assertEqual, which results in marking the test case as FAIL by the framework.
I have a script that use Capybara to publish links in Google+. I would like to have tests to cover this functionality. Usually Capybara is using as a tool for writing Integration tests. In may case i need to test Capybara itself.
I see 3 possible ways:
stub capybara's method (but in this case i test nothing but just stubbed methods)
test capybara agains saved HTML/JS page (that will help me understand that i did not break anything during refactoring)
do not test at all (no comments here)
Have you ever faced such a problem?
If you register different drivers for your app and your test code, possibly manage the sessions manually depending on how you're using it in your app, and make sure you're careful with Capybaras setting's you should be able to go with option 2. You have to be careful with Capybaras settings because most of them are global so changing them for your tests will also change them for your app.
so I'm working on a website here and I would like to run multiple browser tests at one time. What I mean by this is it should perform my smoke tests on ie, firefox and chrome at the same time and report back each browser results. I'm currently only testing with ie with rpsec and watir-webdriver but would like to automate for the other 2 browsers. Are there any existing gems out there (I haven't been able to find any), if not what would be the best way to go around solving this issue?
You should try WatirGrid.
It won't make all the work for you but it will give you a platform to launch multiple tests at once. The you can just launch the same test 3 times changing the target browser and the grid will handle where they will be executed.
Why don't need anything except watir-webdriver to run multiple browsers on the same machine.
ie = Watir::Browser.new :ie
firefox = Watir::Browser.new :firefox
chrome = Watir::Browser.new :chrome
opera = Watir::Browser.new :opera
If you have multiple machines or VMs to work with, Jenkins in the answer. My approach is similar to Chuck's, but instead of a flat configuration file I let Jenkins prompt for these values via drop-down menu, etc. Jenkins is easy to set up and can automatically distribute test jobs to any available machine for testing.
So, I click "Google Search Test" and select "Internet Explorer"... then I do the same thing and select a different browser. Concurrent tests in various browsers, with HTML/email output and a great log history.
I'll also be writing more about this, but I'm still on vacation!
Here is an example of configuration file (these assign default values if for example Jenkins is not used to launch them). NOTE: "||=" means "if nil, use this value. If not nil, use the current value". I'm only setting values if Jenkins has not already.
ENV['BROWSER'] ||= "firefox"
ENV['ENVIRONMENT'] ||= "qa"
ENV['LIMIT'] ||= "10"
ENV['DISTRICT'] ||= "any"
ENV['TYPE'] ||= "pkg-new"
# Not necessary, but added for sanity/cleanliness:
$type = ENV['TYPE'].downcase
$browser = ENV['BROWSER'].downcase
$env = ENV['ENVIRONMENT'].downcase
$district = ENV['DISTRICT'].downcase
puts "\t** Testing #{$env.upcase} using #{$browser.upcase}... **"
The Jenkins portion is surprisingly easy - so easy I didn't think it was set up. You create a Variable for your script, and whatever you name the variable becomes ENV["VariableName"] - and is immediately available to your script.
So I have a variable named "BROWSER" that is set by a drop down with Firefox, IE and Chrome options. The user has no room to confuse the script with free text, and they can run a custom test whenever they want. My Devs/PMs/Users love me :D.
If you want to run the exact same test code for the tests you will need to externalize the browser type, either as an environment variable, or a YAML file or somesuch.
Ruby has some stuff that makes dealing with yaml files super easy (I need to write a blog posting on this) so you can put something at the top of your script that calls a method to get the config info and then set the browser type accordingly.
In my testconfig.yml YAML file I have:
global:
browser: ie #possible values: ie, ff, chrome
note I don't currently test against opera (market segment too small) or it would be in the list of possible values. The comment is just there to make life easy on whoever might have to edit that file.
I have a read_config method defined in a readconfig.rb file which looks (in part) like this
require 'yaml'
def read_config
config = YAML.load_file('testconfig.yml')
$browser_type = config['global']['browser']
end
And at the top of my tests there is code like this
require 'rubygems'
require 'readconfig'
require 'watir-webdriver'
read_config
$browser = Watir::Browser.new $browser_type.to_sym
This way I can have a different config file on each system (which also sets up a lot of other things like the current passwords (changed on a regular basis), which test environment to use, and settings for each environment for stuff like the test server URL's, database server and name, etc. When developing tests a simple change to the config file lets me run all the tests facing a given browser. or if I want to run in parallel I can have the systems setup with their own customized config file, let them pull the current scripts from source control, and then run them against whatever browser, server etc is configured in the config file.
This is probably dirt simple stuff to any accomplished ruby dev, but it's like magic for any of us new to ruby, and especially for getting hard-coded values OUT of my scripts and into one single place where I can control and change them.
I'm building VS.NEt 2010 Load Test solution.
Everything works really good except one thing. When I record .webtest script - it grabs the site domain name, like so:
http://test1/page1
http://test1/page2
So the test1 is hardcoded in the script.
What I would like to do is to run same load test again different test environment - the goal is to compare two environment without rewriting the recording.
I see that Run Settings has "Context Parameters" - is this it?
For for a recorded .webtest, this article shows using the context parameters with the {{parameterName}} syntax for form parameters, and can indeed be used for the server name.
From inside a coded test (which inherits from WebTest), you can access it with:
this.Context["KeyName"]
The problem: toggle javascript support without restarting firefox (nor resorting to different driver) during cucumber test run.
If Firefox's prefutils were exposed to javascript in a web page, that would make it possible. But it is not the case.
So, is there a plugin that does it? Or is there another way to solve the problem? Or is there a good tutorial (that highlights the exposing bit) on how to make such a plugin?
Edit
On a second thought, how would javascript be of any help once it is disabled? Probably the whole idea is a bit screwed.
I assume that your tests run with normal web content privileges. In that case, they aren't going to be able to affect browser settings such as whether JavaScript is enabled (I assume that's what you mean by "toggle JavaScript support").
I'd implement a simple XPCOM component with a method to turn JS support on and off (by setting the appropriate pref). You can expose it as a JavaScript global property so that your tests can access it. See Expose an XPCOM component to javascript in a web page for more details. Package your component in an extension and make sure it is installed in the Firefox instance where your tests are running.
If you want to access the preferences API directly from your content script, you can add the following prefs to Firefox, either in about:config or by adding the following lines to prefs.js in your profile directory:
user_pref("capability.principal.codebase.p1.granted", "UniversalXPConnect UniversalBrowserRead UniversalBrowserWrite UniversalPreferencesRead UniversalPreferencesWrite UniversalFileRead");
user_pref("capability.principal.codebase.p1.id", "http://www.example.com");
user_pref("capability.principal.codebase.p1.subjectName", "");`
user_pref("signed.applets.codebase_principal_support", true);
Replace www.example.com with the domain that you want to grant the privileges to. Also add this line to your JS code before you call the preferences API:
netscape.security.PrivilegeManager.enablePrivilege('UniversalXPConnect');
A local file (something loaded from file:///) is allowed to request additional privileges. Normally you would get a prompt asking whether you want to allow access - you can "auto-accept" the prompt by adding the following lines to prefs.js in the Firefox profile:
user_pref("capability.principal.codebase.p0.granted", "UniversalXPConnect");
user_pref("capability.principal.codebase.p0.id", "file://");
user_pref("capability.principal.codebase.p0.subjectName", "");
You page can then do:
netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
var branch = Components.classes["#mozilla.org/preferences-service;1"]
.getService(Components.interfaces.nsIPrefBranch);
branch.setBoolPref("javascript.enabled", false);
This will definitely work if your page is a local file. Judging by the error message however, you are currently running code from about:blank. It might be that changing capability.principal.codebase.p0.id into about:blank or into moz-safe-about:blank will allow that page to get extended privileges as well but I am not sure.
However, none of this will really help if JavaScript is already disabled and you need to enable it. This can only be solved by writing an extension and adding it to the test profile. JavaScript in Firefox extensions works regardless of this setting.
That means you need Javascript to toggle enabling or disabling Javascript.
function setJavascriptPref(bool) {
prefs = Components.classes["#mozilla.org/preferences-service;1"]
.getService(Components.interfaces.nsIPrefBranch);
prefs.setBoolPref("javascript.enabled", bool);
}