Custom app scheme

[ap4y]

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.

[tcoulter]

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

[listrophy]

@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]

+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]

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]

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]

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

[listrophy]

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

[listrophy]

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.