I am automating android app tests with Appium, and I need to split my test script in half while the app is still running.
The first script initiates a log into the app, and the next script achieves it. Therefore the second script must get the app in the exact same state as it was left by the first step. The app cannot be closed meanwhile.
Is there a way to do this, and if there is, how?
Thank you!
This is quite simple.
Create your test suite directory and insert Initialization file into it.
In the Initialization file do the following setup:
Suite Setup Open Application
Suite Teardown Close All Apps
Then then in the scripts in this directory do not Open Application, just add your Appium keywords and those will use the current open application.
I use this when I need to do something in iOS application (AppiumLibrary), then do operation over same data on web client (SeleniumLibrary) and then finish in iOS and finally check in web client/database.
The file structure is something like this:
__init__.robot
01_login_appium.robot
02_do_appium_stuff1.robot
03_do_selenium_stuff1.robot
04_do_appium_stuff2.robot
...
Alternatively if you just want to have separate script for logging to reuse in scripts, I prefer to create keyword resource file for setup, logging or other common tasks where I would encapsulate several steps in such keyword and reuse it in setup for different scripts.
Related
I have converted a Win32 Application to UWP using MakeAppX and it doesn't seem to run. When I click the icon in the start menu literally nothing happens except a busy icon briefly appears on the cursor.
I completed the same process with Notepad++ and all it's DLLs and that worked fine (using the exact same manifest file, just changing the exe)
My questions are:
Where does the UWP save files that it creates/temporary files etc? If I run an executable and it generates files next to it, where would that be when you run a UWP?
Can I set that location in the AppxManifest?
Is there anyway to see if it has run correctly or not?
Edit:
Could this be a file permissions issue? My application needs to write to 'C:\MyFolder' & creates a folder with a load of files next to the executable upon startup and that doesn't happen.
So looking into this a bit more I came across this blog which discusses preparing for conversion. I think the above file accesses probably contravene the following:
Your app writes to the install directory for your app. For example, your app writes to a log file that you put in the same directory as your exe. This isn't supported, so you'll need to find another location, like the local app data store.
This looks like a fairly halting issue, am I correct in that assumption?
If your app is writing to the install directory you will need to change that code to write to your local app data folder instead, as the preparation guide calls out.
Write operations to the install directory are not allowed in order to ensure the ability for the app deployment stack to perform seamless, differential updates and clean uninstalls of your app.
Btw, to debug through your app launch failures you can do the following in Visual Studio: Debug -> Other Debug Target -> Debug Installed App Package -> select your app from the list of installed apps.
I have two WPF applications in the same solution. One is a configuration helper for the other and needs to be run before the 'big' app is run. In the VS Setup project I have included the Primary Output from both applications.
I want to run the configuration helper during the Commit phase of setup so I added a Custom Action consisting of the Primary Output of configuration helper and marked the Installer Class as false.
When I run the resulting msi, both applications are installed in the same folder as desired, but I then get an error that 'a program run as part of the setup did not finish as expected.' The msi then uninstalls.
I was hoping the configuration helper would be kicked off as the msi exits, but would also be happy with the installer hanging open until the configuration helper exits.
What am I missing?
The program you ran as a custom action has failed, probably crashed. It may need some extra error checking or tracing to see what's going on. Programs that run as custom actions are not in the same environment as running them from the interactive user's desktop. The working directory is probably not what you expect (so file paths must be specified in full) and it's probably running with the system account, because that's the way Everyone installs work, so any assumptions about user locations (including the interactive user's desktop, user folders, access to the network, access to databases, ability to show forms) will be wrong and are likely to be failure points. It's better to run configuration tools like this when the app first starts because you are now running in a normal user environment.
Application
I have an angularjs application that is built by grunt which uses grunt to inject environment variables (like API endpoints) into the angularjs code. However this problem is more specific to grunt applications being deployed in docker containers.
Motivation
I've just recently started trying to integrate docker into the deployment process (something similar to this) but realized I don't know how to best get the environment variables into the application anymore. I'll describe the sequence of events:
Make changes to my code
Build a complete docker image that accepts API endpoints as environment variables
Push the docker image to my server
Run a container based off this new image
As you can see, grunt build occurs in step 2, but the environment variables are not available until step 4.
Possible Solution
I could wrap the call to start the static server for my angular application in a small bash script which creates a javascript file containing the environment variable. I could then add a <script> tag in my index.html to import it and then start the server as usual, with everything working. However that feels like I'm sidestepping grunt inappropriately.
Does anyone know of a straightforward way to inject environment variables into client side code around the same time the connect:dist:keepalive task runs? To clarify, I'm already using the ng-constant grunt task but that can only access environment variables at build time, not server startup time.
Background
In an ASP.NET site, I'm using a code documentation tool called Nocco. Nocco is a command line tool that you explicitly run on a particular code file to output an HTML rendered version of that code and it's documentation. I've currently setup some code in my Global_asax.Application_Start method to crawl through a couple directories and process all the code files in each directory.
Problem
Ultimately, putting it in Global_asax.Applicaton_Start means that it is building the Nocco documentation, which takes ~1 seconds per file, at the beginning of each session - not only once per deployment. This seems inefficient and an ultimate waste of the user's time while the page is loading.
Question
Is it possible to execute code internal to the ASP.NET application (such as a class method) as a post build event? I know that I could convert this part of my setup to a standalone application or even a batch script, but I've had this question for other circumstances as well and have wondered whether or not it's possible.
You could do your generation in Warm up script, here is the link for IIS 7.5
http://blogs.iis.net/thomad/archive/2009/10/14/now-available-the-iis-7-5-application-warm-up-module.aspx
or you can exclude code documentation functionality in separate assembly and include it in standalone app and call it as a external command from project Build events
I have an asp.net update web app. Users go the the page, hit the update button and the program runs. We also want this program to run as a scheduled task everynight. Is this possible? How would you handle this?
thanks
You could create a shortcut on your program to a page on your web app (say update.aspx?command=update) and then have your server's scheduler set to run that shortcut at the time you wish.
I would only recommend that you use a page which has nothing on it and will only respond to a specific command, that way you lower the risk of your page being "tripped" when you don't want it to be.
A better way would be to break the application up into a domain layer dll, then your aspx page could use that dll, and you could also write a console app that used the same dll. You could setup a scheduled task to run the console app nightly.