This repository has been archived by the owner. It is now read-only.

Custom app scheme #21

Closed
wants to merge 5 commits into
base: master
from

Conversation

Projects
None yet
4 participants
@ap4y

ap4y commented Mar 13, 2013

Right now scheme for xcodebuild and app name for instruments are calculated from workspace file name. I think it would be useful to provide ability to change this behaviour. For example, I'm using special target/scheme for UIAutomation tests with networking stubs.

I have added argument :app_name for rake tasks :compile and :test(including device specific tests). This :argument is optional and can be omitted.

ap4y added some commits Mar 12, 2013

added custom constructor for Bwoken::Build with optional app_name par…
…ameter. This parameter will be used to resolve scheme name and app path for custom application names
- added optional parameter app_name to run_all and run_one methods, t…
…his parameter will be passed to the run method

- added parameter app_name to the run method, this parameter will be passed to the new app_name property of the Bwoken::Script
- added parameter app_name to the #cmd method, this parameter will be used during build path resolving
@tcoulter

This comment has been minimized.

Show comment
Hide comment
@tcoulter

tcoulter Apr 9, 2013

I'd like to have this as well. Our project's scheme and .workspace filename don't match.

tcoulter commented Apr 9, 2013

I'd like to have this as well. Our project's scheme and .workspace filename don't match.

@listrophy

This comment has been minimized.

Show comment
Hide comment
@listrophy

listrophy Apr 15, 2013

Member

@ap4y @tcoulter I'm seriously considering abandoning rake as the top-level test runner. I like what @ap4y did with allowing an app_name, but should it really be the one and only argument passed to a rake task? And if we start adding more and more arguments, we run into connascence of position problems. 😦

Anyway, I'm thinking test should be run with a bwoken executable, passing options in a normal, POSIX-like way. Kinda like:

$ bwoken --simulator --app-name=Foo --target=iphone my_test

Thoughts?

Member

listrophy commented Apr 15, 2013

@ap4y @tcoulter I'm seriously considering abandoning rake as the top-level test runner. I like what @ap4y did with allowing an app_name, but should it really be the one and only argument passed to a rake task? And if we start adding more and more arguments, we run into connascence of position problems. 😦

Anyway, I'm thinking test should be run with a bwoken executable, passing options in a normal, POSIX-like way. Kinda like:

$ bwoken --simulator --app-name=Foo --target=iphone my_test

Thoughts?

@tcoulter

This comment has been minimized.

Show comment
Hide comment
@tcoulter

tcoulter Apr 15, 2013

+1. Allows for extensibility later on.

I plan on contributing to bwoken significantly soon. Our own test runner (which we're disbanding in favor of bwoken) has other options like custom trace templates, etc., which required a few monkey-patches in a custom rakefile to get the same features out of bwoken. Actually, we had to monkey patch just to get it running, as we have something of a non-standard environment. I'm all for this.

tcoulter commented Apr 15, 2013

+1. Allows for extensibility later on.

I plan on contributing to bwoken significantly soon. Our own test runner (which we're disbanding in favor of bwoken) has other options like custom trace templates, etc., which required a few monkey-patches in a custom rakefile to get the same features out of bwoken. Actually, we had to monkey patch just to get it running, as we have something of a non-standard environment. I'm all for this.

@ap4y

This comment has been minimized.

Show comment
Hide comment
@ap4y

ap4y Apr 15, 2013

I'm for stand-alone runner too. Executing rake with parameters kind of unnatural for me, and I definitely prefer working with something like OptionParser rather that rake parameters. I think this will be a good step towards the configurable runner.

ap4y commented Apr 15, 2013

I'm for stand-alone runner too. Executing rake with parameters kind of unnatural for me, and I definitely prefer working with something like OptionParser rather that rake parameters. I think this will be a good step towards the configurable runner.

@ap4y

This comment has been minimized.

Show comment
Hide comment
@ap4y

ap4y May 16, 2013

I noticed solution for similar problem in xcodebuild gem. Instead of using plain rake task parameters, we can encapsulate all task logic into subclass of the Rake::TaskLib. Example here. So, rake tasks will be configurable and invocation process will be simple. What do you think?

ap4y commented May 16, 2013

I noticed solution for similar problem in xcodebuild gem. Instead of using plain rake task parameters, we can encapsulate all task logic into subclass of the Rake::TaskLib. Example here. So, rake tasks will be configurable and invocation process will be simple. What do you think?

@luketheobscure

This comment has been minimized.

Show comment
Hide comment
@luketheobscure

luketheobscure Jul 30, 2013

Any progress on this? I was considering making the same change that @ap4y submitted.

luketheobscure commented Jul 30, 2013

Any progress on this? I was considering making the same change that @ap4y submitted.

@listrophy

This comment has been minimized.

Show comment
Hide comment
@listrophy

listrophy Jul 30, 2013

Member

@luketheobscure no progress... lots on my plate, but that's a terrible excuse.

Member

listrophy commented Jul 30, 2013

@luketheobscure no progress... lots on my plate, but that's a terrible excuse.

@listrophy

This comment has been minimized.

Show comment
Hide comment
@listrophy

listrophy Nov 1, 2013

Member

I believe the original intent of this PR is now satisfied with #43 merged into master and released as 2.0.0.beta.2.

I'm closing this, but feel free to ask me to re-open (or just create a new issue) if the new code doesn't satisfy your needs.

Thanks everyone for the discussion on this thread. It's resulted in a new direction for bwoken, and I'm really happy about it.

Member

listrophy commented Nov 1, 2013

I believe the original intent of this PR is now satisfied with #43 merged into master and released as 2.0.0.beta.2.

I'm closing this, but feel free to ask me to re-open (or just create a new issue) if the new code doesn't satisfy your needs.

Thanks everyone for the discussion on this thread. It's resulted in a new direction for bwoken, and I'm really happy about it.

@listrophy listrophy closed this Nov 1, 2013

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.