I used Microsoft Test Manager to create a test for a log on page (not locally hosted) and recorded this. All steps were executed without errors.
Then I've created a Coded UI test project in Visual Studio 2013.
I added a Coded UI Test with the existing recording.
I ran the test and I got the message below:
"FailedToPerformActionOnHiddenControlException: Cannot perform 'SetProperty of Text with value " on the username field.
I received this message when using the existing recording, but also if I record using the recording function in Visual Studio.
Has someone got experience with Coded UI Tests and maybe give me an example as to how to set it up.
If I understand correctly, you're basically trying to have Coded UI input a value into an HtmlInput control that's a text box on a web page. The error message "FailedToPerformActionOnHiddenControlException: Cannot perform 'SetProperty of Text with value" normally means that the value you're trying to submit isn't able to be taken by the control, either because a value isn't accepted (example, numeric values in a name field) or because it's more characters than can be accepted by the field. It could also be that the recording isn't defining the object properly, and that the property Text isn't an option on the control that was found.
So, confirm these three things:
1. The control you're tying to send value to is actually an HtmlInput. You can't send the Text property to, for example, an `HtmlDiv`.
2. The value you're submitting is a valid value for your control (you're not trying to submit numbers, for example, into a field that won't accept them).
3. The value you're submitting is within the length limit for the field.
If I were a betting man, I would say that you probably don't have the object defined properly. Take a look at the SearchProperties of the control in question first and make sure that it matches the HTML on the page itself.
Do I need to set a standard environment for testing on an other server.
I develop the Coded UI test project in a workspace on a development environment, but I need the tests to be run on a acceptation environment (the recorded tests are executed on the acceptation environment).
I read it's easy to setup this environment though, but what is best practise?
Is it better to execute it on the same environment?
Here's a code snippet:
[TestMethod]
public void TestLogonToAccount()
{
// To generate code for this test, select "Generate Code for Coded UI Test" from the shortcut menu and select one of the menu items.
this.UIMap.Enterusername();
this.UIMap.Enterpassword();
this.UIMap.Clickonlogin();
this.UIMap.ClickonCentral();
this.UIMap.Searchforemailaddress();
this.UIMap.Clickonlogin1();
}
I forgot an important part regarding the login recording test in MTM.
I just tried to play the steps again and got this error:
Playback of the selected sections of the action recording could not be completed The playback failed to find the control with the
given search properties. Additional Details: TechnologyName: 'MSAA'
Name: '' ClassName: 'MozillaWindowClass' ControlType: 'Window'
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
I recall having seen at some point screen shots of a select list of QUnit test modules in the test runner toolbar of QUnit. My impression was that selecting one of the modules in the select list would cause that module's tests to be run.
Question: Does such a feature actually exist OOB for QUnit? I know one can set filter via the URL but I would like a more "discoverable" option.
Thanks!
The select list only shows itself if you have defined more than one module in your test suite.
Also, make sure that your test suite is ready before QUnit initializes itself. i.e. QUnit initializes itself when the page finishes loading (the onload event). If you happen to define your test suite after this, then you have to call the (undocumented) QUnit.load() method to notify QUnit that your test suite has been defined.
Demo: http://jsfiddle.net/brianpeiris/98fc8/show/
So lets say I am doing a Test Complete keyword test. If something fails in it the text stops . Actually what I have founded out is that if i have 8 checkpoints if the 4th one fails the rest will always fail after it. So i get a "test execution was interrupted" error. Thats fine but it doesnt finish out the test and close the application. The reason this is an issue is because any tests after it will fail because the application is still left open. I could rewrite these tests so that the application is open when they start but is there a way to kill and application after your tests fail? If the tests pass the application is closed.
You need to organize your tests with test items. In this case, you create at least 3 test items: the first one starts the application, the second performs the test and the third closes the application. If an error occurs during execution of the second test, this second test execution is ended and TestComplete runs the third finalization test item.
Information on test items can be found in the Tests and Test Items help topic. Please note that you need to specify the Test Item value in the Stop on error column for the needed test item (the second one in the above example). Information on this and other columns can be found here. The column is hidden by default and you need to add it: right-click the header of the test items list and select Field Chooser. After this, drag the needed column to the header from the Field Chooser dialog.
Find more information on this solution in Stopping Tests on Errors and Exceptions.
Alternative solution is using the OnLogError or OnStopTest event handlers. Find description of how to handle standard TestComplete events in the Creating Event Handlers for TestComplete Events help topic.
Perhaps I'm oversimplifying, but could it be the setting for the test playback? Pls check the following page and let me know if it helps: http://support.smartbear.com/viewarticle/28751/.
If that doesn't work feel free to repost in the SmartBear Forum: http://community.smartbear.com/
The support team is monitoring the forum and I'm sure they'll be happy to help.
Test driven development on wikipedia says first develop a test that will fail because the feature does not exist. Then build the code to pass the test. What does this test look like?
How do you figure out what test will best represent the feature you want to create?
Can someone give an example?
Like if I make a logout button feature to a web application then would the test be hitting the page looking for the button? or what?
I heard test driven is nice for regression testing, I just don't know how to start integrating it with my work.
Well obviously there are areas that are more suited for TDD than others, and running frontend development is one of the areas that I find difficult to do TDD on. But you can.
You can use WATIN or WebAii to do that kind of test. You could then:
Write a test that checks if a button exists on the page ... fail it, then implement it, and pass
Write a test that clicks the button, and checks for something to change on the frontend, fail it, implement feature and pass the test.
But normally you would test the logic behind the actions that you do. You would test the logout functionality on your authenticationservice, that is called by your eventhandler in webforms, or the controller actions in MVC.
What does this test look like?
A test has 3 parts.
it sets up a context
it performs an action
it makes an assertion that the action did what it was supposed to do
How do you figure out what test will best represent the feature you want to create?
Tests are not based on features (unless you are talking about a high level framework like cucumber), they are based on "units" of code. Typically a unit is a function, and you will write multiple tests to assert all possible behaviors of that function are working correctly.
Can someone give an example?
It really varies based on the framework you use. Personally, my favorite is shoulda, which is an extension to the ruby Test::Unit framework
Here is a shoulda example from the readme. In the case of a BDD framework like this, contextual setup happens in its own block
class UserTest < Test::Unit::TestCase
context "A User instance" do
setup do
#user = User.find(:first)
end
should "return its full name" do
assert_equal 'John Doe', #user.full_name
end
context "with a profile" do
setup do
#user.profile = Profile.find(:first)
end
should "return true when sent #has_profile?" do
assert #user.has_profile?
end
end
end
end
Like if I make a logout button feature to a web application then would the test be hitting the page looking for the button? or what?
There are 3 main types of tests.
First you have unit tests (which is what people usually assume you are talking about when you talk about TDD testing). A unit test tests a single unit of work and nothing else. This means that if your method usually hits a database, you make sure that it doesn't actually hit that database for the duration of the test (using a technique called "mocking").
Next, you have integration tests. An integration test usually involves interaction with the infrastructure, and are more "full stack" testing. So from your top level API, if you have an insert method, you would go through the full insert, and then test the resulting data in the database. Because there is more setup in these sorts of tests, they shouldn't really be run from developer machines (it is better to automate these on your build server)
Finally, you have UI testing. This is the most unreliable, and requires a UI scripting framework like Selenium or Waitr to automate clicking around your UI. Don't go crazy with this sort of testing, because these tests are notoriously fragile (a small change can break them), and they wont catch whole classes of issues anyways (like styling).
the unit test would be calling the logout function and verifying that the expected results occurred (user login record ended, for example)
clicking the logout button would be more like an acceptance test - which is also a good thing to do, and (in my opinion) well within the scope of TDD, but it tests TWO features: the button, and the resulting action
It depends on what platform you are using as to how your tests would appear. TDD is much harder in ASP.NET WebForms than ASP.NET MVC because it's very difficult to mock up the HTTP environment in WebForms to get the expected state of Session, Application, ViewState etc. as opposed to ASP.NET MVC.
A typical test is built around Arrange Act Assert.
// Arrange
... setup needed elements for this atomic test
// Act
... set values and/or call methods
// Assert
... test a single expected outcome
It's very difficult to give deeper examples unless you let us know the platform you plan to code with. Please give us more information.
Say I want to make a function that will add one to a number (really simple example).
First off, write a test that says f(10) == 11, then do one that says f(10) != 10. Then write a function that passes those tests. If you realise the function needs more capabilities, add more tests.
The test would be making sure that when the logout function was executed, the user was successfully logged out. Generally a unit testing framework such as NUnit or MSTest (for .Net stuff) would be used.
Web applications are notoriously hard to unit test because of all the contextual information generally required for the execution of server code on a web server. However, a typical example would mock up that information and call the logout logic, and then verify that the correct result was returned. A loose example is an MVC type test using NUnit and Moq:
[Test]
public void LogoutActionShouldLogTheUserOut()
{
var mockController = new Mock<HomeController>() { CallBase = true };
var result = mockController.Object.Logout() as ViewResult;
Assert.That(result.ViewName == "LogoutSuccess",
"Logout function did not return logout view!");
}
This is a loose example because really it's just testing that the "LogoutSuccess" view was returned, and not that any logout logic was executed. In a real test I would mock an HttpContext and ensure the session was cleared or whatever, but I just copied this ;)
Unit tests would not be testing that a UI element was properly wired up to an event handler. If you wanted to ensure that the whole application was working from top to bottom, this would be called integration testing, and you would use something besides unit tests for this. Tools such as Selenium are commonly used for web integration tests, whereas macro recording programs are often used for desktop applications.