Re: [MacRuby-devel] testing macruby/hotcocoa apps

2009-05-12 Thread Eloy Duran 

Hi Matt,

Testing is indeed an area I find interesting. But it's not so much  
that I like testing itself, but rather the results that one can  
achieve with it. Be it fixing bugs or rigorously refactoring. Real UI  
testing, like Squish does, is very cumbersome imo, maybe that's why  
that testing framework is called Cucumber? ;-)


But maybe the level of GUI testing you are talking about isn't that  
high as Squish does?
For instance, I wouldn't care how much tweets were visible, because  
that's just an issue of how big a table view should be which is a  
design issue and really annoying to test as you have to keep updating  
your tests after design changes (brittle/annoying). Rather I find it  
more interesting to test if an NSArrayController which is backing a  
NSTableView contains the correct result set _after_ a NSButton was  
pushed. This is behaviour which shouldn't break and thus the ratio of  
the amount of time spent on writing tests vs how usable they are is  
much better.


As you may know, Manfred is talking about testing on the rubyonosx  
conference. We have discussed the realm of UI testing and come to the  
conclusion above. Which also means I'll be adding some helpers to  
Rucola like the push_button helper:


describe "TweetController" do
  before do
@person = Person.create(:name => "lrz")
@tweets = Array.new(50) {|i| Tweet.create(:tweetee =>  
@person, :message => "Hey Ninh, this is cool vid number #{i}. I swear  
it's not a Hernandez one!") }

  end

  it "should have assigned all tweets from the specified person to  
the tweets array controller" do

personSearchField.stringValue = @person.name
push_button searchButton
tweetsController.arrangedObjects.should == @tweets
  end
end

The push_button helper is theoretical, but very easy to implement, as  
a control knows its target and the action to call. The other code is  
already possible with the Rucola test case helper. Basically this is a  
regular functional test and a much higher level test than this is not  
interesting in general imo.


(If you're wondering which test framework I use; test/spec. It's imo  
the sweetest balance between Test::Unit and rSpec like frameworks.)


Of course you are free to create such a framework and I would surely  
help out wherever I could with improving testing :-)
However, I must say that I don't think it's what's really needed right  
now. What imo is much much more important to the users of HotCocoa,  
and developers, is a full test suite for HotCocoa itself. I'm sure  
Rich and I will come to this topic at the conference as well, but it  
should be discussed openly as well.


Cheers,
Eloy

On May 12, 2009, at 8:18 AM, Matt Aimonetti wrote:


This is a very interesting topic and probably Eloy's favorite theme ;)

Overall, the Ruby community strongly believes in testing, as a  
matter of fact we have so many testing frameworks I did not even  
test them all: test/unit, rspec, shoulda, bacon, context, cucumber  
etc


Doing unit tests on your "models" isn't really a challenge, we  
probably all know how to do that and we have the tools to do so. The  
real challenge is to test expected behaviors at the highest level:  
the GUI.


I talked with few very smart people during RailsConf and before that  
I talked to some Java friends of mine developing swing apps. It  
seems that everybody agrees that testing behavio(u)rs at the GUI  
level is really challenging. The approval testing approach is nice  
but it's kind of a pain since you need to validate every UI change.
What would be totally awesome is a solution like Webrat + Cucumber http://cukes.info/ 
 but for Cocoa apps developed using MacRuby.


Think about it, would it be really nice if we could do something  
like that:


Given I'm a valid twitter user
When I enter my credentials
Then I should see the last 50 tweets sent by my friends

To do this kind of magic, we need to be able to parse the UI, the  
good thing is that thanks to MacRuby, we have an easy way to do full  
introspection on all the objects.
So, in theory, we should be able to walk down the 'tree', starting  
at the NSApp level, pick a window, a view, an tableview, a row and  
check on its content after a button was clicked. This way, we can  
trigger UI components and see resulting behavior.
We could even imagine some sort of selenium-type DSL to drive our  
tests in real time :)


Before I get too excited, I'd like to hear what you guys think and  
what you believe you need to write better code?


- Matt

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #54: build on Leopard fails on readline

2009-05-12 Thread MacRuby 
#54: build on Leopard fails on readline
-+--
 Reporter:  edaroc...@…  |Owner:  lsansone...@…
 Type:  defect   |   Status:  closed   
 Priority:  blocker  |Milestone:   
Component:  MacRuby  |   Resolution:  invalid  
 Keywords:  readline |  
-+--
Changes (by eloy.de.en...@…):

  * status:  reopened => closed
  * resolution:  => invalid


Comment:

 Replying to [comment:9 edaroc...@…]:
 > Replying to [comment:8 eloy.de.en...@…]:
 >
 > Still fighting with this, wishing I could do all the cool, new stuff
 with MacRuby 0.4 and HotCocoa.
 >
 > You must realize that this is all leftover issues from following the
 Hivelogic article on installing Ruby on Rails on Tiger.  Readline was
 recommended there: http://hivelogic.com/articles/view/ruby-rails-mongrel-
 mysql-osx
 >
 > Now with Leopard, it is not needed for installing Ruby from source, and
 it is a problem.

 Ah yes, that dreaded article which destroyed so many installations…

 So there are basically three options to fix this. You can do it by hand as
 you did, but this can still leave you with many broken stuff and will lead
 to hard to debug annoying issues. The best solution imo is a re-
 installation of at least the system. You can do an “archive & install”
 which means your user data will preserved but the system will be removed
 and re-installed.

 Good luck!

 PS: As stated before, this isn't an issue with MacRuby, so I'm labelling
 it as “invalid”

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #54: build on Leopard fails on readline

2009-05-12 Thread MacRuby 
#54: build on Leopard fails on readline
-+--
 Reporter:  edaroc...@…  |Owner:  lsansone...@…
 Type:  defect   |   Status:  closed   
 Priority:  blocker  |Milestone:   
Component:  MacRuby  |   Resolution:  invalid  
 Keywords:  readline |  
-+--

Comment(by edaroc...@…):

 Do take note that 'rake clean' did not clean out the compiled code from
 the source directory (if it is supposed to - seems like part of my
 difficulty).

 Also, I did upgrade to Leopard from a fresh install.  Migration Assistant
 copied in my custom software installs from /usr/local, which is desirable.
 I don't think System was touched, because Dan did teach me to always use
 /usr/local!

 http://hivelogic.com/articles/view/using_usr_local

 RyanR>

 Replying to [comment:11 eloy.de.en...@…]:
 >
 > Ah yes, that dreaded article which destroyed so many installations…
 >
 > So there are basically three options to fix this. You can do it by hand
 as you did, but this can still leave you with many broken stuff and will
 lead to hard to debug annoying issues. The best solution imo is a re-
 installation of at least the system. You can do an “archive & install”
 which means your user data will preserved but the system will be removed
 and re-installed.
 >
 > Good luck!
 >
 > PS: As stated before, this isn't an issue with MacRuby, so I'm labelling
 it as “invalid”

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #54: build on Leopard fails on readline

2009-05-12 Thread MacRuby 
#54: build on Leopard fails on readline
-+--
 Reporter:  edaroc...@…  |Owner:  lsansone...@…
 Type:  defect   |   Status:  closed   
 Priority:  blocker  |Milestone:   
Component:  MacRuby  |   Resolution:  invalid  
 Keywords:  readline |  
-+--

Comment(by edaroc...@…):

 Here's the results from a fresh git clone and post-rake. Notice that
 ext/readline/extconf.h still remains after the clean.

 {{{
 /usr/local/src/macruby(master) $ git status
 # On branch master
 # Untracked files:
 #   (use "git add ..." to include in what will be committed)
 #
 #   .ext/
 #   .installed.list
 #   array.o
 #   bignum.o
 #   blockinlining.o
 #   bs.o
 #   class.o
 #   compar.o
 #   compile.o
 #   complex.o
 #   cont.o
 #   debug.o
 #   dir.o
 #   dln.o
 #   dmyext.o
 #   dtrace.h
 #   enc/ascii.o
 #   encoding.o
 #   enum.o
 #   enumerator.o
 #   error.o
 #   eval.o
 #   ext/bigdecimal/Makefile
 #   ext/bigdecimal/bigdecimal.o
 #   ext/bigdecimal/extconf.h
 #   ext/bigdecimal/mkmf.log
 #   ext/continuation/Makefile
 #   ext/continuation/continuation.o
 #   ext/continuation/extconf.h
 #   ext/curses/Makefile
 #   ext/curses/curses.o
 #   ext/curses/extconf.h
 #   ext/curses/mkmf.log
 #   ext/dbm/Makefile
 #   ext/dbm/dbm.o
 #   ext/dbm/extconf.h
 #   ext/dbm/mkmf.log
 #   ext/digest/Makefile
 #   ext/digest/bubblebabble/Makefile
 #   ext/digest/bubblebabble/bubblebabble.o
 #   ext/digest/bubblebabble/extconf.h
 #   ext/digest/digest.o
 #   ext/digest/extconf.h
 #   ext/digest/md5/Makefile
 #   ext/digest/md5/extconf.h
 #   ext/digest/md5/md5init.o
 #   ext/digest/md5/md5ossl.o
 #   ext/digest/md5/mkmf.log
 #   ext/digest/rmd160/Makefile
 #   ext/digest/rmd160/extconf.h
 #   ext/digest/rmd160/mkmf.log
 #   ext/digest/rmd160/rmd160init.o
 #   ext/digest/rmd160/rmd160ossl.o
 #   ext/digest/sha1/Makefile
 #   ext/digest/sha1/extconf.h
 #   ext/digest/sha1/mkmf.log
 #   ext/digest/sha1/sha1init.o
 #   ext/digest/sha1/sha1ossl.o
 #   ext/digest/sha2/Makefile
 #   ext/digest/sha2/extconf.h
 #   ext/digest/sha2/mkmf.log
 #   ext/digest/sha2/sha2.o
 #   ext/digest/sha2/sha2init.o
 #   ext/dl/Makefile
 #   ext/dl/callback.h
 #   ext/dl/cfunc.o
 #   ext/dl/cptr.o
 #   ext/dl/dl.o
 #   ext/dl/extconf.h
 #   ext/dl/handle.o
 #   ext/dl/mkmf.log
 #   ext/dl/win32/Makefile
 #   ext/etc/Makefile
 #   ext/etc/etc.o
 #   ext/etc/extconf.h
 #   ext/etc/mkmf.log
 #   ext/fcntl/Makefile
 #   ext/fcntl/extconf.h
 #   ext/fcntl/fcntl.o
 #   ext/fiber/Makefile
 #   ext/fiber/extconf.h
 #   ext/fiber/fiber.o
 #   ext/gdbm/Makefile
 #   ext/gdbm/mkmf.log
 #   ext/iconv/Makefile
 #   ext/iconv/extconf.h
 #   ext/iconv/iconv.o
 #   ext/iconv/mkmf.log
 #   ext/io/wait/Makefile
 #   ext/io/wait/extconf.h
 #   ext/io/wait/mkmf.log
 #   ext/io/wait/wait.o
 #   ext/json/Makefile
 #   ext/json/ext/generator/Makefile
 #   ext/json/ext/generator/extconf.h
 #   ext/json/ext/generator/generator.o
 #   ext/json/ext/generator/mkmf.log
 #   ext/json/ext/generator/unicode.o
 #   ext/json/ext/parser/Makefile
 #   ext/json/ext/parser/extconf.h
 #   ext/json/ext/parser/mkmf.log
 #   ext/json/ext/parser/parser.o
 #   ext/json/ext/parser/unicode.o
 #   ext/json/extconf.h
 #   ext/nkf/Makefile
 #   ext/nkf/extconf.h
 #   ext/nkf/nkf.o
 #   ext/openssl/Makefile
 #   ext/openssl/extconf.h
 #   ext/openssl/mkmf.log
 #   ext/openssl/openssl_missing.o
 #   ext/openssl/ossl.o
 #   ext/openssl/ossl_asn1.o
 #   ext/openssl/ossl_bio.o
 #   ext/openssl/ossl_bn.o
 #   ext/openssl/ossl_cipher.o
 #   ext/openssl/ossl_config.o
 #   ext/openssl/ossl_digest.o
 #   ext/openssl/ossl_engine.o
 #   ext/openssl/ossl_hmac.o
 #   ext/openssl/ossl_ns_spki.o
 #   ext/openssl/ossl_ocsp.o
 #   ext/openssl/ossl_pkcs12.o
 #   ext/openssl/ossl_pkcs5.o
 #   ext/openssl/ossl_pkcs7.o
 #   ext/openssl/ossl_pkey.o
 #   ext/openssl/ossl_pkey_dh.o
 #   ext/openssl/ossl_pkey_dsa.o
 #   ext/openssl/ossl_pkey_ec.o
 #   ext/openssl/ossl_pkey_rsa.o
 #   ext/openssl/ossl_rand.o
 #   ext/openssl/ossl_ssl.o
 #   ext/openssl/ossl_ssl_session.o
 #   ext/openssl/ossl_x509.o
 #   ext/openssl/ossl_x509attr.o
 #   ext/openssl/ossl_x509cert.o
 #   ext/openssl/ossl_x509crl.o
 #   ext/openssl/ossl_x509ext.o
 #

[MacRuby-devel] #54: build on Leopard fails on readline

2009-05-12 Thread K H 
Hi, I couldn't build MacRuby and gave up, until I saw this post. I've  
followed both the Tiger and Leopard version of that article. Can you  
briefly explain what's wrong with that article or with readline? Thanks.



On May 12, 2009, at 12:56 AM, macruby-devel- 
requ...@lists.macosforge.org wrote:



Ah yes, that dreaded article which destroyed so many installations?


___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] #54: build on Leopard fails on readline

2009-05-12 Thread Eloy Duran 
Oh hey, thanks for pointing me to it again. There's nothing wrong with  
that article I failed at properly looking at the article. I think the  
layout instantly reminded me of an article which suggested installing  
ruby into /usr which a lot of people did and consequently broke their  
installations.


Mea culpa.

So the problem of this ticket is an architecture problem. Normally  
when you just use "./configure --prefix=/usr/local" then the resulting  
binaries will only be for the current architecture it's running on. In  
this case i386. MacRuby however, is configure to be compiled for more  
architectures than just i386. This is for compatibility of your app on  
different machines and thus necessary. However, you cannot build  
something (MacRuby) for architectures which it's dependencies do not  
contain.


To sum up; your dependencies need to at least include support for the  
architectures that the product is being build for.


In this case readline was compiled without support for other archs  
than the current one, which is ok normally, but MacRuby can't be build  
for more than just i386 and so it fails.


Solutions are build MacRuby for the current arch, or make sure MacRuby  
uses libs in /usr instead of /usr/local when compiling. I wouldn't go  
with the former, it will bite you later on when deploying.


I hope this explains it a bit more. And I'll add this as a comment to  
the ticket so others won't be confused due to my error.


Cheers,
Eloy

On 12 mei 2009, at 16:18, K H wrote:

Hi, I couldn't build MacRuby and gave up, until I saw this post.  
I've followed both the Tiger and Leopard version of that article.  
Can you briefly explain what's wrong with that article or with  
readline? Thanks.



On May 12, 2009, at 12:56 AM, macruby-devel-requ...@lists.macosforge.org 
 wrote:



Ah yes, that dreaded article which destroyed so many installations?


___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #54: build on Leopard fails on readline

2009-05-12 Thread MacRuby 
#54: build on Leopard fails on readline
-+--
 Reporter:  edaroc...@…  |Owner:  lsansone...@…
 Type:  defect   |   Status:  closed   
 Priority:  blocker  |Milestone:   
Component:  MacRuby  |   Resolution:  invalid  
 Keywords:  readline |  
-+--

Comment(by eloy.de.en...@…):

 Oh hey, thanks for pointing me to it again. There's nothing wrong with
 that article I failed at properly looking at the article. I think the
 layout instantly reminded me of an article which suggested installing ruby
 into /usr which a lot of people did and consequently broke their
 installations.

 Mea culpa.

 So the problem of this ticket is an architecture problem. Normally when
 you just use "./configure --prefix=/usr/local" then the resulting binaries
 will only be for the current architecture it's running on. In this case
 i386. MacRuby however, is configure to be compiled for more architectures
 than just i386. This is for compatibility of your app on different
 machines and thus necessary. However, you cannot build something (MacRuby)
 for architectures which it's dependencies do not contain.

 To sum up; your dependencies need to at least include support for the
 architectures that the product is being build for.

 In this case readline was compiled without support for other archs than
 the current one, which is ok normally, but MacRuby can't be build for more
 than just i386 and so it fails.

 Solutions are build MacRuby for the current arch, or make sure MacRuby
 uses libs in /usr instead of /usr/local when compiling. I wouldn't go with
 the former, it will bite you later on when deploying.

 I hope this explains it a bit more. And I'll add this as a comment to the
 ticket so others won't be confused due to my error.

 Cheers,
 Eloy

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #54: build on Leopard fails on readline

2009-05-12 Thread MacRuby 
#54: build on Leopard fails on readline
-+--
 Reporter:  edaroc...@…  |Owner:  lsansone...@…
 Type:  defect   |   Status:  closed   
 Priority:  blocker  |Milestone:   
Component:  MacRuby  |   Resolution:  invalid  
 Keywords:  readline |  
-+--

Comment(by eloy.de.en...@…):

 For the "clean" problem, could you file a new ticket? This one is a bit
 noisy and on another topic. Thanks

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] testing macruby/hotcocoa apps

2009-05-12 Thread Brian Marick 
I think it's prudent to make UI testing as much like unit testing as  
possible. Tools and tests that poke at the GUI from "outside" are  
notoriously fragile. I gave a talk at Mountain West RubyConf on using  
TDD for user interfaces (using RubyCocoa, but the idea is the same for  
MacRuby).



This week, I'll be updating my tooling for MacRuby and starting to use  
it to reimplement the /Developer/Examples Objective-C samples.


(Shameless plug: There's a more detailed description of the testing  
approach in my RubyCocoa book: .)


-
Brian Marick, independent consultant
Mostly on agile methods with a testing slant
www.exampler.com, www.exampler.com/blog, www.twitter.com/marick

___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] Key-value observing

2009-05-12 Thread Jeremy Voorhis 
Hello,

I've been learning Cocoa, Objective-C and macruby in tandem and I was
just wondering, are there any plans to integrate the key-value
observing protocol with the attr_accessor family of methods? With a
little experimentation, I found KVO is definitely possible with
macruby, but the syntax is less than ideal (transcript made with the
0.4 release).

~ % macirb
>> class Notifier
>>   attr_accessor :value
>> end
=> nil
>> class Observer
>>   def observeValueForKeyPath(path, ofObject:object, change:change, 
>> context:context) puts change end
>> end
=> nil
>> n = Notifier.new
=> #
>> n.addObserver(Observer.new, forKeyPath:'value', options:0, context:nil)
=> nil
>> n.value = 42
=> 42
>> n.setValue 42
{"kind"=>1}
=> nil

Best,

Jeremy Voorhis
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] testing macruby/hotcocoa apps

2009-05-12 Thread Alex Vollmer 

On May 11, 2009, at May 11, 11:18 PM, Matt Aimonetti wrote:

Before I get too excited, I'd like to hear what you guys think and  
what you believe you need to write better code?


I love the concept, but have often found UI testing tools to be  
lacking. I think that's because in the past I was always hoping to  
write *unit*-tests for UIs which near-impossible to do without simply  
re-asserting the implementation (which makes for a terrible unit- 
test). Having seen the approach taken by Cucumber I'm more hopeful  
that this would get some traction. Hell, even to have something that  
would step through all the little manual scenarios automatically would  
be a great tool to have.


So, yeah, Matt. I'm all for it!

—Alex


http://alexvollmer.com
http://moochbot.com




___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] testing macruby/hotcocoa apps

2009-05-12 Thread Jeremy Voorhis 
I second the idea also. Tools like Squish have their place, but as a
solo/hobbyist developer, I'd much rather put some faith in Apple's
efforts to test that scrollbars scroll properly, buttons dispatch to
actions, etc. and focus on how *my* code constructs views, binds data
and generally assert that the state of my views is what I expect.

On a related note, I just created my first custom view in macruby
(just a throw-away tutorial app) and wondered what the best strategy
for testing Cocoa graphics code might be. The most obvious answer
would be to mock the critical parts of the API I am calling, but in
practice I find that approach often leads to building a second
implementation which isn't guaranteed to be any more correct than the
code I am testing, and can become as much a liability as it is an
asset. Does anyone know of a good model for testing graphics code that
can actually account for how views *appear*?

Best,

Jeremy Voorhis

On Tue, May 12, 2009 at 2:45 PM, Alex Vollmer  wrote:
> On May 11, 2009, at May 11, 11:18 PM, Matt Aimonetti wrote:
>
> Before I get too excited, I'd like to hear what you guys think and what you
> believe you need to write better code?
>
> I love the concept, but have often found UI testing tools to be lacking. I
> think that's because in the past I was always hoping to write *unit*-tests
> for UIs which near-impossible to do without simply re-asserting the
> implementation (which makes for a terrible unit-test). Having seen the
> approach taken by Cucumber I'm more hopeful that this would get some
> traction. Hell, even to have something that would step through all the
> little manual scenarios automatically would be a great tool to have.
> So, yeah, Matt. I'm all for it!
> —Alex
> 
> http://alexvollmer.com
> http://moochbot.com
>
>
>
>
> ___
> MacRuby-devel mailing list
> MacRuby-devel@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
>
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel