ZenTest scans your target and unit-test code and writes your missing
code based on simple naming rules, enabling XP at a much quicker
pace. ZenTest only works with Ruby and Test::Unit.
There are two strategies intended for ZenTest: test conformance
auditing and rapid XP.
For auditing, ZenTest provides an excellent means of finding methods
that have slipped through the testing process. I've run it against my
own software and found I missed a lot in a well tested
package. Writing those tests found 4 bugs I had no idea existed.
ZenTest can also be used to evaluate generated code and execute your
tests, allowing for very rapid development of both tests and
implementation.
** FEATURES/PROBLEMS:
+ Scans your ruby code and tests and generates missing methods for you.
+ Includes a very helpful filter for Test::Unit output called unit_diff.rb
+ Includes a LinuxJournal article on testing with ZenTest written by Pat Eyler.
+ 3 minor enhancements
+ Able to audit standard class library (so now we can audit rubicon!).
+ Able to map against class methods (self.blah <=> test_class_blah).
+ Added -I=rubypath support
+ 4 bug fixes
+ bug:1151 Fixed stupid problem w/ unit_diff.
+ bug:1454 code generation correctly matches class/module for nested classes.
+ bug:1455 Updated method mapping to work on all operators listed in my quickref.
+ Realized I'm a moron and did NOT release in March like I thought...
Thank you very much for it! I've always wanted to learn about unit testing, but
never got around to do it because no tutorial I could find was really
practical. Now I can easily begin learning through use by letting ZenTest
generate tests around some of my old untested code! Thanks a lot for this great
tool!
I see this notation, which appears to be undefined outside of hash literals, all over the
place. What does it do? The online version of the pickaxe book doesn't have it.
You are very welcome. I look forward to your feedback.
···
On Oct 18, 2005, at 5:44 AM, Christophe Grandsire wrote:
Selon Ryan Davis <ryand-ruby@zenspider.com>:
ZenTest version 2.4.0 has been released!
Thank you very much for it! I've always wanted to learn about unit testing, but
never got around to do it because no tutorial I could find was really
practical. Now I can easily begin learning through use by letting ZenTest
generate tests around some of my old untested code! Thanks a lot for this great
tool!
I see this notation, which appears to be undefined outside of hash literals, all over the
place. What does it do? The online version of the pickaxe book doesn't have it.
Basically, those are hash literals too. They look a bit like keyword arguments because of the syntactic sugar that Ruby allows:
- If the only argument of a method is a hash, you can lose the {}: "mymethod({:foo => "bar"})" can be written "mymethod(:foo => "bar")"
- Parentheses around the parameter list of a method are optional:
"mymethod(foo)" can be written "mymethod foo"
Add both rules, and you get exactly the syntax of your example. "redirect_to" and "render" are actually just methods that take hash arguments ('redirect_to :action => "elsewhere"' is just another way to write 'redirect_to({:action => "elsewhere"})' in a clearer and key-hit saving way ), and the two syntactic sugar rules allows one to use them in a keyword+keyword argument fashion. Neat isn't it?
As for why the online Pickaxe doesn't have it, it may be because the hash syntactic sugar is only present since Ruby 1.8, while the online Pickaxe covers Ruby 1.6. But I could be wrong.
You could, if you so desired, then pass this hash to a method:
render(hash)
You could combine the two to get:
render({ :action => "overthere" })
Ruby actually lets you omit the curly braces when the hash is the last parameter of a method:
render :action => "overthere"
The above just calls render with a single hash as the parameter, containing :action. You can specify as many arguments as you want, and as long as the hash parameters are the last ones, it all Just Works, with the last parameter of the method receiving the hash.
- Jamis
···
On Oct 18, 2005, at 3:26 PM, Warren Seltzer wrote:
I see this notation, which appears to be undefined outside of hash literals, all over the
place. What does it do? The online version of the pickaxe book doesn't have it.
It works not only when the method has only one argument, but always
with the last argument.
$ irb
irb(main):001:0> def show(*args) p args end
=> nil
irb(main):002:0> show 1, 2, 3, 5 => 6
[1, 2, 3, {5=>6}]
=> nil
regards,
brian
···
On 18/10/05, Christophe Grandsire <christophe.grandsire@free.fr> wrote:
En réponse à Warren Seltzer :
> I see this notation, which appears to be undefined outside of hash literals, all over the
> place. What does it do? The online version of the pickaxe book doesn't have it.
>
> Here's a rails example:
>
> def do_something
> redirect_to :action => "elsewhere"
> render :action => "overthere" # raises DoubleRenderError
> end
>
Basically, those are hash literals too. They look a bit like keyword
arguments because of the syntactic sugar that Ruby allows:
- If the only argument of a method is a hash, you can lose the {}:
"mymethod({:foo => "bar"})" can be written "mymethod(:foo => "bar")"
- Parentheses around the parameter list of a method are optional:
"mymethod(foo)" can be written "mymethod foo"
Add both rules, and you get exactly the syntax of your example.
"redirect_to" and "render" are actually just methods that take hash
arguments ('redirect_to :action => "elsewhere"' is just another way to
write 'redirect_to({:action => "elsewhere"})' in a clearer and key-hit
saving way ), and the two syntactic sugar rules allows one to use
them in a keyword+keyword argument fashion. Neat isn't it?
As for why the online Pickaxe doesn't have it, it may be because the
hash syntactic sugar is only present since Ruby 1.8, while the online
Pickaxe covers Ruby 1.6. But I could be wrong.
--
Christophe Grandsire.
As for why the online Pickaxe doesn't have it, it may be because the hash syntactic sugar is only present since Ruby 1.8, while the online Pickaxe covers Ruby 1.6. But I could be wrong.
It works not only when the method has only one argument, but always
with the last argument.
$ irb
irb(main):001:0> def show(*args) p args end
=> nil
irb(main):002:0> show 1, 2, 3, 5 => 6
[1, 2, 3, {5=>6}]
=> nil
Thanks for pointing that out. I've only ever seen this with methods that have only the hash as argument (mainly rails examples), so I didn't know normal parameters are allowed as long as they preceed the hash.
find(:all, :conditions => "whatever...") # first arg not part of hash
James Edward Gray II
···
On Oct 18, 2005, at 5:03 PM, Christophe Grandsire wrote:
Thanks for pointing that out. I've only ever seen this with methods that have only the hash as argument (mainly rails examples), so I didn't know normal parameters are allowed as long as they preceed the hash.
), and the two syntactic sugar rules allows one to use them in a keyword+keyword argument fashion. Neat isn't it? 