I'd like to find a programatic way to reset the location warnings for the iOS simulator so that it can be automated before test case. I'm specifically trying to incorporate this with the KIF testing framework.
Any API will do, private or public.
Have you tried to change the application bundle identifier? It is not clean solution but it can help.
You can also change it programmatically writing skript and running it as one of the build phases.
UPDATE
In your Build Phases section of Project configuration add new phase Run Script
You can use something like that:
echo $CONFIGURATION
if [ "$CONFIGURATION" == "Debug" ]; then
${SRCROOT}/build.sh
fi
And build.sh could look like this:
#!/bin/bash
newIdentifier = "com.mydomain.myapp_new"
/usr/libexec/PlistBuddy -c "Set : CFBundleIdentifier ${newIdentifier}" "MyApp-Info.plist"
You will find way to incrementally change bundle identifier
You can find more here: http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man8/PlistBuddy.8.html
Related
I'm working on a Kotlin multi-platform project, and I need my JS tests to run on Node.js but with custom command line arguments (specifically I need node to run with the --expose-gc flag, because some tests need to trigger garbage collection).
Looking at the documentation for the Gradle Kotlin JS DSL I didn't find any mention of how to do that; does anyone know whether it's at all possible and how?
Unfortunately can not answer your question directly, but there is some suggestion to help you with reverse engineering.
Let's start from some example. We have Gradle tasks to run our project using webpack's dev server such as browserDevelopmentRun, browserProductionRun (not sure if multi-platform projects have it, but JS projects do). We can add:
println(tasks.named("browserProductionRun").get().javaClass)
to build.gradle.kts to find out the exact class used for this task. When we sync Gradle, it outputs:
org.jetbrains.kotlin.gradle.targets.js.webpack.KotlinWebpack_Decorated
Now we know the exact class of this task so we can investigate its API. The auto completion or navigating inside of the KotlinWebpack class helps us to find out that it has a helpful nodeArgs property to configure NodeJS arguments for it, so we can set them, for example:
tasks.named("browserProductionRun", org.jetbrains.kotlin.gradle.targets.js.webpack.KotlinWebpack::class).get().nodeArgs.add("--trace-deprecation")
Getting back to your question.
In your case I guess you need to investigate the browserTest task. Let's get some info about it by adding:
println(tasks.named("browserTest").get().javaClass)
to build.gradle.kts - a-ha - it seems to be of the org.jetbrains.kotlin.gradle.targets.js.testing.KotlinJsTest_Decorated type. Let's check what's inside. Open KotlinJsTest.kt somehow - for example by typing its name into the window being opened by CMD + Shift + O (make sure to select "All Places" here) or just by typing its name somewhere in build.gradle.kts and navigating inside it.
The only interesting thing I see inside this open class is the following block:
override fun createTestExecutionSpec(): TCServiceMessagesTestExecutionSpec {
val forkOptions = DefaultProcessForkOptions(fileResolver)
forkOptions.workingDir = npmProject.dir
forkOptions.executable = nodeJs.requireConfigured().nodeExecutable
val nodeJsArgs = mutableListOf<String>()
return testFramework!!.createTestExecutionSpec(
task = this,
forkOptions = forkOptions,
nodeJsArgs = nodeJsArgs,
debug = debug
)
}
So maybe it can work out to create your own extension of this class, override its createTestExecutionSpec method and provide nodeJsArgs as you need inside it. After that you'll be needing to declare another Gradle task to launch tests inside build.gradle.kts which will use this new extended class.
I'm trying out NetBeans for editing Groovy code. (I'm new to Groovy, and it's been a long time since I did any Java development).
At some point I installed the Groovy plugin via the "plugins" tool. But it does not have the green checkmark under "active", and choosing the Groovy plugin does not make the Activate/Deactivate/Uninstall buttons available. Oh well...
So let's create a project...
Choose "new project". I'm choosing "Java with Maven" just because it's the first one.
Hit "Finish"...and voila, I have a project.
Let's create a file...
Right click the project package in the left pane, choose "new"
Choose "Groovy Script" for a type, hit "finish"
Hey, I have a very simple script. Looks like it should say "Hello chris!" when done.
Hit the "play" button on the toolbar....things appear in the output window.
But wait a minute...the output is "Hello World!", and it should be "Hello chris!" It looks like "HelloWorld" is coming out of "Mavenproject1.java".
How can I (or can I) just run my script from within NetBeans?
UPDATE: per #andrewJames suggestion, I tried working that tutorial. (It looks like the tutorial may be a bit out of date.)
I created a "Java Ant" project, as that was the only one that offered me the option of not creating a "Main Class File".
I created the Java form, and the Groovy class, as directed.
When I run the project, I get an error message saying "Error running forked groovyc".
I get that same error whether I'm running on a machine with a groovyc executable or not, so I suspect that there's something about the configuration that I need to change in order to point to the groovyc executable.
Probably something to do with the build.xml file...but I can't seem to figure out how to edit that to change the search path for the groovyc step.
I had the same problem that NB doesn't run a Groovy script out of the IDE like Eclipse does. I logged an issue and spent more than a year on the netbeans-dev mailing list advocating for it. Often replied to with "we'll be happy to review your pull request" type of stuff. Eventually, when I rage quit the mailing list with a scathing message, Geertjan replied to the issue with a solution.
So, in short, use the old plugin to create a Groovy project and change line 26 in groovy-build.xml to
<groovyc srcdir="#{srcdir}" sourcepath="#{sourcepath}" destdir="#{destdir}" encoding="${source.encoding}" excludes="#{excludes}" includeAntRuntime="true" fork="false">
You can then run your script with Shift+F6.
The project needs the Groovy jars added. It works for me on NB 11, 12 & 13 with Groovy 2.x and Java 8, 11 & 14 so far. I haven't tried it with Groovy 3.x as the groovy-all.jar is deprecated so you'll have to maven or manually manage the Groovy jars.
Also, I collaborated a bit with someone on a new plugin. It works as is but new development has stalled.
I am using JHipster 3.4.0 with gradle.
Excuse me for newbie questions.
There are times when I don't trust hot reloads and want to do full clean build.
However, executing 'build' task always lead to running integration tests.
Doing something like
test {
// include '**/*UnitTest*'
// include '**/*IntTest*'
// ignoreFailures true
// reports.html.enabled = false
}
in build.gradle doesn't help.
So how do I skip integration tests for full clean build?
And just to confirm, the task to do full clean build is 'build' right?
Thanks in advance,
Sam
To partially answer my own questions. Just found out the command line
gradle build -x test
will do the trick. But I don't think that answer my question of why comment out test task above doesn't work
The reason why the test are still running, when commenting the includes is, that test task has default values (if you don't overwrite them). So all classes in src/main/test are used as test classes. Your way by passing a command line parameter is the way to go.
(I'm using InstallShield2012 V.18)
In setup.rul I defined a function per prototype declaration, included the file with the function definition and compiled it successfully (InstallShield compile).
Now I'd like to test this function (only).
I don't want to run the whole installation, not even test (Ctrl-T) because I want to avoid a complete re-build which takes too long time to do it often.
Is there a way to test only the custom function in InstallShield or per command line?
Not really although I can give you some tips.
Create a dummy feature with a release flag of DEVONLY.
Create a dummy component for that feature.
Create a ProductConfiguration that builds a single MSI with no EXE and a release flag of DEVONLY.
Building this production configuration will be very fast. A couple seconds on my laptop with an SSD. You can selectivly include other features through the use of release flags if you need certain components in order to setup the test environment for your CA.
Another strategy is to develop your CA in a test harness project and then transplant the code into your real installer when you know it all works.
Christopher, thanks for this fast reply. I have to put my answer here because commenting was restricted, because too long.
I also thought about using such a workaround but first wanted to avoid it if possible.
But ok, now I tried these steps, 1 and 2 no problem, but 3: InstallShield didn't allow me to configure a Product Configuration without Setup.exe in my .ism file (although we have IS2012 Pro).
Then I tried to do it in a Basic MSI Project (is that what you meant?), which really builds in very short time. And now I can see my scripting during Test Release, yeah :-)
To "transplant" my script now to the main ism I'm missing an export function for .rul files as it exists for custom actions, but there is only a import. So I will have to copy-paste while switching between ism files, but never mind.
I'm having problems with my cucumber/capybara setup and was wondering...
How can I get more information out of cucumber and capybara to see what's going on?
I've tried running
bundle exec cucumber features/myfeature.feature -v -b -x
But that just shows which rb files are loaded and which feature is being loaded. I want to know what on earth it is running. All it shows me is:
F_______________F
Which is completely unhelpful.
What kind of information are you looking to see?
You can try adding the --format=pretty option - this will print out each step as it's being processed, with the file location of the step definition that matches it, so you can see the status of each step (passed, failed, skipped, pending, etc.)
I miss some real logging support in Cucumber, in order to debug steps, but it seems the current way to log from steps is to "announce" messages. Announcements are turned on with the #announce tag. Try tagging your feature/scenario with #announce, that's the best option I've discovered so far.