Hey all! So, as I've been working on a recipe for testing with MacRuby, I realized that it would probably be good to discuss the topic of "blessing" a particular test suite. Obviously, with macgem all of the Ruby test suites are available to use, but for the purposes of tutorials and whatnot, having one default that ships with MacRuby would help reduce confusion and at least get people started on the road to testing. Personally, I think whatever ships with MacRuby should ideally be light-weight, extensible, and integrated. In other words, the heavy hitters like Test::Unit, RSpec, and Shoulda are out. That leaves: -- minitest: The "blessed" test library of Matz Ruby. It's very minimal, but documentation is somewhat lacking. I also couldn't find an easy spot to hook into the API to customize output format. Still, if it's good enough for Matz Ruby... -- bacon: Small, and output is easily customized. I'm currently looking at what would be required to get bacon's output to play nicer with Xcode. The one unknown (for me, at least) is popularity/ familiarity in the larger Ruby community. -- OCUnit: This is the Objective C test library that ships with Xcode. We could put a thin wrapper around it, and then not worry about having to ship a separate test library. The major downside to OCUnit is that it's not very "Ruby-ish". I'm quite enamored with bacon, but I'm worried about the possibility that developers coming from Matz Ruby might start to expect minitest to be included. That might be a remote possibility, though, as it seems like minitest isn't currently that popular. If there are others I missed, or if you disagree with any points, speak up! Cheers, Josh
Hi, As we're targeting 1.9 compatibility, the library that will be shipped with MacRuby is minitest. Atm however, we still have an older version of the stdlib, which means we still ship test-unit. I myself have put my trust in Bacon, and as far as a "blessing" goes, all critical bugs encountered with Bacon have been fixed. Eloy On 9 okt 2009, at 07:58, Josh Ballanco wrote:
Hey all!
So, as I've been working on a recipe for testing with MacRuby, I realized that it would probably be good to discuss the topic of "blessing" a particular test suite. Obviously, with macgem all of the Ruby test suites are available to use, but for the purposes of tutorials and whatnot, having one default that ships with MacRuby would help reduce confusion and at least get people started on the road to testing. Personally, I think whatever ships with MacRuby should ideally be light-weight, extensible, and integrated. In other words, the heavy hitters like Test::Unit, RSpec, and Shoulda are out. That leaves:
-- minitest: The "blessed" test library of Matz Ruby. It's very minimal, but documentation is somewhat lacking. I also couldn't find an easy spot to hook into the API to customize output format. Still, if it's good enough for Matz Ruby...
-- bacon: Small, and output is easily customized. I'm currently looking at what would be required to get bacon's output to play nicer with Xcode. The one unknown (for me, at least) is popularity/ familiarity in the larger Ruby community.
-- OCUnit: This is the Objective C test library that ships with Xcode. We could put a thin wrapper around it, and then not worry about having to ship a separate test library. The major downside to OCUnit is that it's not very "Ruby-ish".
I'm quite enamored with bacon, but I'm worried about the possibility that developers coming from Matz Ruby might start to expect minitest to be included. That might be a remote possibility, though, as it seems like minitest isn't currently that popular. If there are others I missed, or if you disagree with any points, speak up!
Cheers,
Josh _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Just judging by the initial round of twitter / blog postings, the #1 problem people are having trouble with 0.5B1 is obtaining LLVM. Antonio has already put together a nice blog posting about it (http://antoniocangiano.com/2009/10/08/getting-macrubys-compiler-to-work/ ), but shouldn't his instructions be on the MacRuby blog, seeing as how Laurent's announcement is the first thing many people are going to see? Even better, maybe an LLVM package to go along with MacRuby, also linked to on the site? Given that you need a very specific (e.g. recent, from trunk) version of LLVM for MacRuby to work at all, this seems pretty reasonable. If the instructions were "just go grab llvm 2.6" then I might feel differently. - Jordan
Even better, maybe an LLVM package to go along with MacRuby, also linked to on the site? Given that you need a very specific (e.g. recent, from trunk) version of LLVM for MacRuby to work at all, this seems pretty reasonable.
I think Laurent wants to include it directly in the next MacRuby installer. Though I was just thinking we should be careful not to overwrite the version of LLVM the user might have, putting our version in MacRuby's directory, not at the place we MacRuby developers have it installed currently (/usr/local).
If the instructions were "just go grab llvm 2.6" then I might feel differently.
At first I was thinking we might be able to use the final 2.6, but it's in a pretty bad shape. We could not use LLVM 2.5 because of problems regarding exception handling. And it looks like we won't be able to use LLVM 2.6 because of... problems regarding exception handling...
Jordan, Users should not need to obtain and install LLVM. MacRuby uses it statically. There was a mistake in the installer, we forgot to bundle llc (LLVM compiler tool) used by macrubyc, this will be fixed in the upcoming nightly builds then in the next beta. Laurent On Oct 9, 2009, at 1:02 AM, Jordan K. Hubbard wrote:
Just judging by the initial round of twitter / blog postings, the #1 problem people are having trouble with 0.5B1 is obtaining LLVM. Antonio has already put together a nice blog posting about it (http://antoniocangiano.com/2009/10/08/getting-macrubys-compiler-to-work/ ), but shouldn't his instructions be on the MacRuby blog, seeing as how Laurent's announcement is the first thing many people are going to see? Even better, maybe an LLVM package to go along with MacRuby, also linked to on the site? Given that you need a very specific (e.g. recent, from trunk) version of LLVM for MacRuby to work at all, this seems pretty reasonable. If the instructions were "just go grab llvm 2.6" then I might feel differently.
- Jordan
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Ah, OK. Never mind then! On Oct 9, 2009, at 1:56 AM, Laurent Sansonetti wrote:
Jordan,
Users should not need to obtain and install LLVM. MacRuby uses it statically. There was a mistake in the installer, we forgot to bundle llc (LLVM compiler tool) used by macrubyc, this will be fixed in the upcoming nightly builds then in the next beta.
Laurent
On Oct 9, 2009, at 1:02 AM, Jordan K. Hubbard wrote:
Just judging by the initial round of twitter / blog postings, the #1 problem people are having trouble with 0.5B1 is obtaining LLVM. Antonio has already put together a nice blog posting about it (http://antoniocangiano.com/2009/10/08/getting-macrubys-compiler-to-work/ ), but shouldn't his instructions be on the MacRuby blog, seeing as how Laurent's announcement is the first thing many people are going to see? Even better, maybe an LLVM package to go along with MacRuby, also linked to on the site? Given that you need a very specific (e.g. recent, from trunk) version of LLVM for MacRuby to work at all, this seems pretty reasonable. If the instructions were "just go grab llvm 2.6" then I might feel differently.
- Jordan
_______________________________________________ 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
participants (5)
-
Eloy Duran
-
Jordan K. Hubbard
-
Josh Ballanco
-
Laurent Sansonetti
-
Vincent Isambart