I am looking for solution where I can set my javascripts with order and when each script would start it would be independent on previous scripts. So I can run just one script or group of them and it would be working same.
I find that I can create one script file and use #import keyword, something like this:
#import "AddStaticContentMissingName.js"
#import "AddStaticContent.js"
It's working and both scripts are running but second one starts where first one ends and that is what bothers me. I can set first one to end when the second one needs but I don't like it. I just one to script do what should test and then end. So is it possible to before each test restart application or something like that? I want to have UI testing automate as possible so what or you using? Or are you using another tool then UI Automation?
Bonus question: I was looking for solution how to run this from command line and/or with Xcode Server. I guess Xcode Server is problem but for command line there is a solution. Problem with solution which I found is that I isn't portable right? I don't have any way how can I add some script to my repository and if someone try use it there would be problems with paths. Example of command I found:
instruments \
-w your_ios_udid \
-t "/Applications/Xcode.app/Contents/Applications/Instruments.app/Contents/PlugIns/AutomationInstrument.bundle/Contents/Resources/Automation.tracetemplate" \
name_of_your_app \
-e UIASCRIPT absolute_path_to_the_test_file
If you want to reset the application between scripts, you need to do it yourself with a combination of app code and UIAutomation code. (Apple will be replacing Instruments with something that works better, but for now this is the only way.)
For example, if your application doesn't use the "shake" gesture for anything, you could use that to trigger a restart within your app (not closing it, just returning it to a known state). Then at the top of every UIAutomation script, you could just call the method for the shake gesture.
In the testing framework we wrote, we set up our own RPC channel to allow us to expose non-UI functionality (like resetting the app) to automation scripts. It really doesn't matter what system you use to make it happen, as long as you can reliably get the app to a known state.
I might be too late for this but it's totally possible to accomplish what you want. Basically, create a bash script (or any other script) and include the commands to run your two automation scripts:
#!/bin/bash
instruments -w <UDID> -t <template> <app> -e UIASCRIPT <script1>
instruments -w <UDID> -t <template> <app> -e UIASCRIPT <script2>
Run that and your app will restart after the first script creating a trace file per run.
Related
I am wondering how to
1) how to run model directly in Eclipse without GUI - just run the model like run other java codes in Eclipse and print out something i am interested.
2) how to run it in headless mode without even Eclipse - I plan to deploy my model in a remote server, which the server or my own PC could run the model automatically at a specific time of the day.
3) Every time when I change the code, I have to launch a new GUI in order to reflect the code changes. It takes at least 5 seconds to open the GUI. This is very inefficient way of model development and debugging. What is the better strategy available?
For headless, or batch, running of models, take a look at the Repast Batch Getting Started Guide. This can either allow you to run multiple runs without a GUI, as in (1), or if you look at section 9.2, it will allow you to run from the command line without invoking Eclipse, as in your case (2). If you want more control, I'd suggest looking at the InstanceRunner class and utilize the complete_model.jar payload that is generated by the Batch GUI or batch_runner.jar.
Unarchive the complete_model.jar
Then use the InstanceRunner class from the command line, like so from within the complete_model directory
java -Xmx512m -cp "../lib/*" repast.simphony.batch.InstanceRunner \
-pxml ../scenario.rs/batch_params.xml \
-scenario ../scenario.rs \
-id $instance \
-pinput localParamFile.txt
where the localParamFile.txt is an unrolled parameter file specifying the combination(s) of parameters to run (see the unrolledParamFile.txt within the payload for an example) and if you're running just one instance this would just be one line.
Some background: I have a project based on ESP-IDF which has a complex builtin building system which you plug into with your own makefile (their documentation on using it).
This works fine (apart from occasional horrendous build times), but now I wanted to add a build target for unit tests for a component, which requires building this component against another project (the unit-test-app).
So, I need another build target that calls another make with another makefile and directory. Something like this works fine:
make -C $(path to unit-test-app) \
EXTRA_COMPONENT_DIRS=$(my component directory) \
TEST_COMPONENTS=$(my component name) \
ESPPORT=$(my serial port) \
-j clean app-flash monitor
But only if I execute it from bash. If I try to execute it from another makefile, it breaks either not finding some header files (the include path is different between the main and unit test project) or ignores the change of project (-C argument) and executes the main project build.
What I tried:
using $(MAKE), $(shell which $(MAKE)) and make in the custom target
using env -i $(shell which $(MAKE) ) -C ... with forwarding required environment arguments to the child make
using bash -l make -C ... and bash -c make -C ...
What works but is a dirty hack: using echo $(MAKE) -C ... in the make target and then running $(make tests) from the command line.
As far as I know, this is an issue of the parent makefile setting something up in the environment that I did not separate the child makefile from. What else can I do to separate these two?
UPDATE: I have created an example project that shows the issue more clearly, please look at the top Makefile of https://github.com/chanibal/esp-idf-template-with-unit-tests
I reproduced your situation as you are describing it and everything works fine, both if I call the inner make from bash or from the outer make.
So there is something you are not telling us that is causing the failure.
On the other hand, I feel there are several irrelevant details in your description.
So, I suggest you try to further isolate the problem, removing irrelevant stuff, and reproducing the problem only from the description in your question, and then when you are doing it you will probably find out what is breaking. If not, then post here the minimal setup with all the other details that are needed for the failure to occur.
By the way, what you are doing is not good practice, so maybe just avoiding it would solve your problems.
What I mean is, there is one case and one case only, where recursive make is good practice: make -C ${directory}
where in directory you have a completely self-contained build, not using anything from the outside.
It seems this is not the case for you, because you seem to be passing some outside location variables. This kind of recursive make is bad practice and should be avoided.
I've got an ant target ant server that runs a Java application which logs to the console. I need to run a new ant target ant server-gui which also logs to the console. But when I run ant server the logging prevents me from running any new ant targets.
When I enter ^c (which is the only way I know of to get out of situations like that) it kills the Java application. I need both to run. What keystroke will get me out of that "input" mode and able to run new terminal commands?
UPDATE: I haven't found a direct solution to getting out of that mode I mentioned, but opening a new tab/window in terminal does the trick. I can run as many any commands as I'd like that way. Still looking for a good solution to get out the "input" mode, though!
UPDATE 2: #abcdef pointed out another post that has an even more elegant solution.
There are a few ways to do this, assuming you are on *nix
1) Run the ant command with a & at the end to tell *nix to run the command in the background
2) Run the command with nohup at the beginning (https://en.wikipedia.org/wiki/Nohup)
3) when the process is running press ctrl-z then enter the command bg. This manually forces the command to run in the background
I hope this helps you out
I have written a UI automation script in Instruments and Its working perfectly. Now I want to know is there any way that I simply double click on script and Its start working or at least I don't need to run Xcode for running the script.
instruments -w 1.device_id -t /Developer/Platforms/iPhoneOS.platform/Developer/Library/Instruments/PlugIns/AutomationInstrument.bundle/Contents/Resources/Automation.tracetemplate 2.application -e UIASCRIPT 3.script -e UI-ARESULTSPATH 4.results path
The ones marked with 1. 2. 3. 4. are the variables that you type. Use this code, put in your device id, app, script and result path and run the whole line in Terminal
I am trying to contribute more with couchdb code, but I have really no idea how it is done the right way.
I have cloned the source from apache git repository and built it with
./configure
make && sudo make install
Then I wanted to change a file from the source called couch_httpd_show.erl
Do I need to run make && sudo make install again for every change I make to the source code and want to see how it behaves?
I am sure there's a more practical way to do it, because this approach is a bit time and patience consuming right?
Yes, there is a shortcut.
./configure
make dev
./utils/run
This builds and runs CouchDB entirely in the current directory. Instead of running as a background daemon, CouchDB will run in the foreground and output log messages to the terminal. It uses some local directories to store stuff: ./tmp/log for logs, ./tmp/lib for databases, and (if I remember correctly) ./etc/couch/local_dev.ini for configuration.
If you run this instead:
./utils/run -i
then you will also have an interactive Erlang prompt, which you can use to help debug.
When I work on CouchDB, I run this in the shell:
make dev && ./utils/run -i
After I change some code, I press ^C, up-arrow, return.
When I joined Couchio, I was responsible for production CouchDB deployments. I asked Chris Anderson for advice about something and he said, "Sorry, ask Jan. I've been just using utils/run for years!"
You can rebuild that one file and drop the output beam in place and restart.
erlc <file.erl>
& then copy the .beam file into place. To restart couchdb use either init:restart(). in the erlang shell or POST /_restart to CouchDB.
Although you might want to consider using the commandline erlang & javascript test suite also to ensure you didn't break anything.