In some, or all of my UI testing, the UIApplicationDelegate is completely useless.
Is it possible to start with a blank screen and then I can present a view controller as part of my testing code?
This is not possible.
The UI testing framework allows you to interact with your app only through a proxy, and considers the app a black box. You have no control on it apart from the possibility to set launch arguments and environment variables.
This is an intentional design decision that many acceptance frameworks take, and it is meant to focus the UI tests on the users interaction and how the app responds to it.
You can always leverage the launch arguments or environment variables to pass an instruction to your app to load your desired view controller straight away from the app delegate's applicationDidFinishLaunching(_: withOptions:), for example using a router.
More info can be found here:
http://nshipster.com/launch-arguments-and-environment-variables/
https://github.com/clayallsopp/routable-ios
Related
In my app when the app is resumed from a sleep, I'd like to
reload the page - or ideally, just update specific UI elements.
How can this be done?
Preferably in a platform independent way.
You want to hook into the onResume method in the application module which exposes the event when an app resumes from the background.
https://docs.nativescript.org/api-reference/modules/application.html#onresume
So in your app.js (the entry point of your application), import the module and add the onResume event handler and it can run everytime the app resumes. Now reloading a page will require a little more work. You'd have to use the frame module and find out the current page and do your work, but I'm guessing it can be done with a little effort using the approach mentioned.
UPDATE: based off your comment, you need the reloadPage() method from the ui/frame module. https://docs.nativescript.org/api-reference/modules/_ui_frame_.html#reloadpage
The correct method is reloadPage() in the Frame module (as contributed by #Brad) but the problem is that it's NOT an exposed api.
No problem - just copy/paste it and it works.
The problem is that it basically does a navigateTo() to the currentPage and that effects the navigation history. You have 2 choices - setting clearHistory to true and you lose all history (don't want that) or set clearHistory to false which creates a a duplicate of the current-page (don't want that either). There's also a backstackVisible option but that doesn't help in this scenario.
#Brad tells me that there's api that allows access to the navigation stack - haven't looked into it.
For my app - the user will be at the root page most of the time, so I decided to reload the page only if on the root page and then set clearHistory to true and that works for me.
After writing UI tests with XCTest, I'm trying to change the server the build points to in the Settings app in the simulator. This is so automated tests run in the right place. Is there a way to do this with accessibility and UI testing code?
How can I change this URL?
Edit: #oletha 's answer is perfect. Here's the solution I used in Objective-C:
I set the launch argument to be configServer=#"URL"
for (NSString *launchArgument in [[NSProcessInfo processInfo] arguments]) { if ([launchArgument hasPrefix:#"configServer"]) { return [launchArgument componentsSeparatedByString:#"="].lastObject; } }
You can send a launch argument to the app by setting the launchArguments property before launching the app. You can then set up your app to read the launch argument during launch and set the URL of your mock server when it is launched with that launch argument.
// test code
let app = XCUIApplication()
app.launchArguments = ["UITESTS"]
app.launch()
// app code
if NSProcessInfo.processInfo().arguments.contains("UITESTS") {
// set different server URL
}
You probably want to add the URL switching code in applicationDidFinishLaunching on your app delegate.
As per Xcode 8.2 you cannot automate UI outside your own app's target, so you cannot interact with the Settings app on the device. I feel this is a bug and filed a radar (http://www.openradar.me/27802551), you might want to do the same.
I imagine the URL you're trying to change is stored somewhere in your preferences. If that's the case you could change it dynamically during the execution of your tests using SBTUITestTunnel. This is a 3rd party library that allows to interact with your application from UI Tests, enabling network mocking and monitoring, data injection and more. For your use case it allows to easily update NSUserDefaults.
I have the following question:
I have an application that I'm using Marionette.Layout and this Layout has regions.
I want to add the option to the user to change language(on run time), meaning after the application is already render and the user is working, he can change the language and all the application should be change it to the selected language.
My Question:
1. I need to 'refresh/re-render' all the application, how is this done, I didn't found or I miss it, how to re-render the application?
I already have a a mechanism that the 'templates' are like:
https://github.com/janl/mustache.js/issues/216
This is working when the application is started, the first time, I need on run time to re-render/refresh with the new data
Unfortunately there isn't anything in the Marionette to do this for you. You will have to write the code to re-render the entire application with the new language setting, yourself.
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.
I want to write a unit test of just the GUI part of my Cocoa application.
In the textbook unit test, there's a test framework and test case that calls the unit under test. All the code below that unit is mocked out. So, both the input and the output are controlled and monitored; only the code in the unit under test is tested.
I want to do the same thing where the unit under test is my GUI:
1) Set up some kind of framework where I can write code that will manipulate and inspect GUI controls.
2) Connect my GUI controls to mocks of my actual code, not to the real instances.
3) Run the test, which manipulates the controls and then checks the mock object to see whether the correct methods were called with the correct parameters and checks the GUI to see whether the responses from the mock object causes the correct changes in the widgets.
Anyone doing this? If so, how? Any ideas on how I could do this?
Thanks,
Pat
(Edit) To give a very specific example, I want to:
1) Write a test case that will select the menu item 'MyMenu' -> 'MyItem'. In this test case, I want to check to see that the method [AppDelegate doMyItem] gets called precisely once and that no other methods in AppDelegate get called.
2) Generate a mock object of AppDelegate. (I know how to do this)
3) Somehow (handwaving here) link my application so that a mock instance of AppDelegate is linked in instead of the real one.
4) Run the test. Watch it fail because 1) I haven't created MyMenu yet. 2) I haven't created MyItem yet. 3) I haven't done the IB work to connect MyItem to [AppDelegate doMyItem], or 4) because I haven't written the 'doMyItem' method yet.
5) Fix the above four issues (one at a time if I'm feeling really pedantic that day).
6) Run the test again and watch it succeed.
Does this make the question clear?
Two principles, two links:
Make the view as dumb as possible, with the passive view pattern: this makes GUI easier to test
Trust but verify: Trust Cocoa implementation of buttons, menus, ... But verify that target and action are correctly connected, that bindings are as expected.
Here are a couple of popular ways of doing this in general (should work with most if not all cocoa compatible languages).
1 - create a callback interface. One of the inputs when creating your GUI elements is an implementation of this interface. When there's a user interaction, the GUI element calls an update function on that interface. Have a real implementation and a test implementation.
2 - Use event-handlers. Register all of your GUI elements with one or more event-handlers, and have the GUI generate events on user interaction. Have an event handler interface with two implementations, again one for real use and one for testing.
Edit: whoops, missed requirement #1. Never done this with OSX specific controls, but in general there are two approaches.
1 - create a script or app that generates user-like input. Has the drawback of not being easy to actually inspect the GUI. You instead need to generate good test cases to make sure that everything that should be there is, and nothing extra is there.
2 - create an interface with a test implementation that replaces the rendering and interface layer. This is easier with libraries like SDL or directFB and less so with with things like the OSX API, win32 API, etc.
Edit: responding to edit in question.
In the case of your example, using a seperate testing app and event handlers here's how it'd look:
Your test application is a simple app or script that starts up your GUI and then generates mouse / keyboard events based on input files. As I've said, never done this in OSX (only QNX). With any luck you'll be able to generate mouse and keyboard events with the API, but you'll have to ask someone else if it's possible.
So create an input for your test-case. The test app will parse this to know what to do. It may be simple XML like this:
<testcase name="blah"><mouseevent x="120" y="175" type="click"/></testcase>
or whatever the mouse sequence may actually be.
When your script executes that command it will click the mouse on that button. Your event handler will pick up on this. But now you should be running your app with a --test flag or somesuch so that it's actually using the test event handler. Instead of doing whatever your app normally does, the test event handler can do some custom action. For instance it may do some of the normal actions (you still need the GUI to respond) and then send a message (via socket, pipe, whatever) to your test app.
Your test app will pick up this message and compare it to what it expects to see. So now maybe your testcase XML looks like this:
<testcase name="blah">
<mouseevent x="120" y="175" type="click"/>
<response>doMyItem() called</response>
</testcase>
If the response generated from the event handler is different, then the test case has failed. You can print out the actual response to help in debugging.
Have you looked into the accessibility framework? It should let one application inspect the UI of another application and generate user-like interaction events.
Accessibility Overview