[MacRuby-devel] Xcode Project Template with Testing Baked In

Eloy Duran eloy.de.enige at gmail.com
Fri Oct 2 12:01:24 PDT 2009


> First, I completely agree on reducing duplicated effort, but I have  
> a few questions.

Sure thing, that's what we're here for :)

> Let me know if you want to move this discussion off list or feel  
> free to just answer these off list.

For details, I think it's best to discuss on IRC freenode #ruby-osx,  
or via IM. My email address is where you can reach me on gtalk/jabber.

> What is the timeline for merging rucola into HotCocoa vs extending  
> HotCocoa to have the functionality that is present in RubyCocoa  
> rucola ?

There wouldn't be much difference in total  development time, so we've  
discussed that for the time being they're gonna be developed  
separately. Because much has to be done on both the libraries core  
code, so it's not an ideal moment to devote time to merging them.

> What are the major blockers/good places to start looking to help out  
> the MacRubyification of the rucola framework ?

Discovering all bugs to be able to run Mocha and ERB (dunno the status  
of the latter).

> Is rucola a command line only generation framework, or will there be  
> support for creating projects in Xcode as well ? My current focus as  
> a new user is helping to smooth the transition for other new users  
> from Obj-c to Ruby development. Being able to stay in Xcode  and use  
> standard templates and IB for initial development really helps ease  
> the transition. Command line generation is fantastic from the  
> 'coming from Rails' perspective, but not so great for the coming  
> from Xcode perspective, where you expect this to be handled by  
> targets and build steps.

It already was possible to do most stuff from XCode. But, admittedly,  
not being a huge user of XCode has lead me to never create xcode  
templates. I would love input on this from users such as yourself,  
because it _should_ be completely transparent.

Also, I would like to clarify that I did _not_ mean that HotCocoa/ 
Rucola would be a standard dependency of an application. I simply  
meant that the test cases, which are run by devs anyways so not a  
problem afaik, would require the test case helpers form the HotCocoa/ 
Rucola gem. The gem will come with MacRuby pre-installed. (At least,  
that's what I remember the last discussion on this topic being  
concluded at.)

So with your additions to the templates, this would still run that  
way, we simply don't include any elaborate helper code. To summarize,  
a standard template created app, would look identically to what your  
additions do, with the exception from any test case helpers, these  
should go into a shared test case helper.

> From the testing perspective: I've only tried naive tests with the  
> standard test::unit style so far but everything seems to be working.  
> What are the missing/broken parts that I haven't run into yet ?

Too much to list actually, but it surrounds meta code mainly, which is  
probably why most simplere uses work. (Try running the test suites of  
test::unit and minitest, see the rake tasks). More importantly, as  
you've noted, test::unit is dropped by upstream in favor of minitest.  
We however still have it in the stdlib and it's unsure as of yet what  
and when this is going to change, so this could potentially make it  
"hard" for users. Although I must admit, I have no experience in  
porting test cases to minitest.

> I understand re: including testing appearing to be supporting it.  
> Could that be reduced by adding comments to the effect that some  
> things may not work to the template or better documentation on what  
> is supported ?

A comment, as a note that it's not stable yet, would already clarify a  
lot yes.

> My main concern here is that people like me who would want to try  
> out MacRuby may have to replicate the admittedly limited integration  
> work and snooping that I've done here (since it is not obvious that  
> it isn't supported, so of course you go to try it out), replicating  
> the effort and running into a disheartening wall anyway.

True, we don't want that.

> Or worse, they could choose not to go beyond initial experiments  
> with MacRuby due to the lack of apparent support for testing. So  
> either way, the current state of testing should probably be  
> addressed somewhere with a call to arms :)

Well, it _is_ being worked on. The reason that might not be apparent,  
is simply because it really _isn't_ stable yet and I always tend to  
wait giving the idea something is "supported" (ugh I hate the  
word ;) ) until we have something to show for it.

In other words, in my opinion, people should not expect everything to  
work yet on MacRuby. If they know this upfront, then there's also no  
reason to judge MacRuby on it and stop using MacRuby. Which is why I'm  
telling all of this in the first place :)

So, since I do wholeheartedly agree with you that we don't want users  
to bump into any walls, I'm gonna apply your patch right now, and we  
will discuss further on the test case helpers as we go :)



PS: Dylan, please do contact me off list to discuss details,  
preferably not by email, it takes me too much time to write them…

> - Dylan
> On Fri, Oct 2, 2009 at 3:31 AM, Eloy Duran <eloy.de.enige at gmail.com>  
> wrote:
> Hey Matt,
>> hmm for once I don't fully agree with Eloy :)
> I'm sure we've disagreed before ;-)
>> But, on the long run this should all move to Rucola to provide one  
>> piece that pulls it all together.
>> It's a small details but I think we do need a solid testing  
>> framework in XCode too. Not everyone will use Rucola and therefore  
>> offering a great test solution for both tools would be great.
> Rucola has always been about allowing Ruby devs _and_ xcode users to  
> use it without knowing the difference. Also, Rucola/HotCocoa will  
> come with MacRuby, so they can use it without knowing so.
>> I don't think Eloy was against such thing but I thought it was  
>> important to mention it.
> I'm against maintaining duplicate stuff. People should just use the  
> code which has been battle tested and has added facilities to make  
> it easier, even if they don't know what it is their using in the  
> bakcground. Ie, the test helper would just require the test case  
> helper, the user doesn't need to know where it actually lives.  
> Adding this to the project template makes people think they have to  
> add facilities themselves imo.
> Eloy
>> On Fri, Oct 2, 2009 at 1:18 AM, Eloy Duran  
>> <eloy.de.enige at gmail.com> wrote:
>> Hi Dylan,
>> So, I've been mucking about with MacRuby lately. It's been fun so  
>> far. Thanks to all the devs for this great project.
>> Welcome!
>> I'm a pretty firm believer in unit testing my Ruby code. I love how  
>> Ruby on Rails and similar frameworks nudge you in the right  
>> direction by baking in an existing testing infrastructure.
>> Great, we agree! :)
>> I've got testing pretty much figured out and was wondering if the  
>> team would be open to modifying the basic Xcode project template to  
>> add unit testing, with a stub test and test_suite file to get  
>> started. This would also involve creating a framework for any  
>> objective-c code that the user writes so that it can be included in  
>> both the .app and the test files.
>> Well, unfortunately atm it's not that easy. Because we currently  
>> can't both run test::unit or minitest properly. I know the  
>> test::unit, which is currently in macruby's trunk, works work the  
>> greater part, but it's not ideal.
>> I have been working on this area for a while now, getting a little  
>> closer every time. This work is part of Rucola, which at some point  
>> will merge with HotCocoa and will provide a classic layout as you  
>> are accustomed to by frameworks such as Rails.
>> At this point, the test framework which we can fully run is Bacon,  
>> which is what I'm gonna base the rest of my current work on.  
>> However, once we can fully run minitest/test::unit we'll support  
>> that as well. More importantly right now is a working mocking and  
>> stubbing lib. My choice is Mocha, but MacRuby is not mature enough  
>> yet to do all the fancy meta stuff that is needed for this.
>> So for the time being, I'd say cool let's add it to the project  
>> template! But, on the long run this should all move to Rucola to  
>> provide one piece that pulls it all together. If you are interested  
>> on working on this, please contact me directly. Anyone can do that  
>> btw.
>> Cheers,
>> Eloy
>> _______________________________________________
>> MacRuby-devel mailing list
>> MacRuby-devel at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>> _______________________________________________
>> MacRuby-devel mailing list
>> MacRuby-devel at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
> _______________________________________________
> MacRuby-devel mailing list
> MacRuby-devel at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
> _______________________________________________
> MacRuby-devel mailing list
> MacRuby-devel at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macruby-devel/attachments/20091002/b6a994dc/attachment-0001.html>

More information about the MacRuby-devel mailing list